From wwwrun@ietfa.amsl.com Tue May 3 12:02:22 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 487AAE08A7; Tue, 3 May 2011 12:02:22 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfa.amsl.com, Subsystem@ietfa.amsl.com, for@ietfa.amsl.com, the@ietfa.amsl.com, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110503190222.487AAE08A7@ietfa.amsl.com> Date: Tue, 3 May 2011 12:02:22 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:02:22 -0000 'State Changes to Waiting for AD Go-Ahead from In Last Call by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfa.amsl.com Tue May 3 12:03:39 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 9D084E0892; Tue, 3 May 2011 12:03:39 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@ietfa.amsl.com, Context@ietfa.amsl.com (SNMP), EngineID@ietfa.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110503190339.9D084E0892@ietfa.amsl.com> Date: Tue, 3 May 2011 12:03:39 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 19:03:39 -0000 'State Changes to Waiting for AD Go-Ahead from In Last Call by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From wwwrun@ietfa.amsl.com Mon May 9 12:17:32 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 2C5D6E0710; Mon, 9 May 2011 12:17:32 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfa.amsl.com, Subsystem@ietfa.amsl.com, for@ietfa.amsl.com, the@ietfa.amsl.com, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110509191732.2C5D6E0710@ietfa.amsl.com> Date: Mon, 9 May 2011 12:17:32 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2011 19:17:32 -0000 'State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Sean Turner' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From internet-drafts@ietf.org Thu May 12 06:26:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E7E07A2; Thu, 12 May 2011 06:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j+Dnrh2jjrvQ; Thu, 12 May 2011 06:26:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E8BE06D6; Thu, 12 May 2011 06:26:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110512132640.6423.6533.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2011 06:26:40 -0700 Cc: simple@ietf.org Subject: [Simple] I-D Action: draft-ietf-simple-msrp-sessmatch-11.txt X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 13:26:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP for Instant Messaging and Presenc= e Leveraging Extensions Working Group of the IETF. Title : Session Matching Update for the Message Session Relay Pr= otocol (MSRP) Author(s) : Christer Holmberg Staffan Blau Filename : draft-ietf-simple-msrp-sessmatch-11.txt Pages : 11 Date : 2011-05-12 This document defines an extension, sessmatch, for the Message Session Relay Protocol (MSRP) session matching procedure of MSRP entities. The extension extends the applicability of MSRP communication to network scenarios where Application Layer Gateway (ALG) functions modify the Session Description Protocol (SDP) MSRP address information. The document also defines a Session Initiation Protocol (SIP) option-tag, sessmatch, that is used by MSRP entities to indicate support of the sessmatch extension. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-simple-msrp-sessmatch-11.txt From christer.holmberg@ericsson.com Thu May 12 06:30:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFBCE06BE for ; Thu, 12 May 2011 06:30:24 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK4ThklWeG0V for ; Thu, 12 May 2011 06:30:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6A017E06C7 for ; Thu, 12 May 2011 06:30:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-e7-4dcbe084f933 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id FD.5D.11171.480EBCD4; Thu, 12 May 2011 15:28:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 12 May 2011 15:28:33 +0200 From: Christer Holmberg To: Simple WG Date: Thu, 12 May 2011 15:28:32 +0200 Thread-Topic: Draft new version: sessmatch-11 Thread-Index: AcwQqH0ZRW7tlOckTQWY/O5umsVXMQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E142BE6@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585194E142BE6ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [Simple] Draft new version: sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2011 13:30:24 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E142BE6ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the discussions that have taken place on the list, and off-line in= Prague, I have submitted a new version of the sessmatch draft. The major changes are: - An option-tag for the sessmatch extension has been added. - A section, describing ALG assumptions, has been added. - The security considerations section has been modified. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585194E142BE6ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on the discussions that have taken place on the= list, and off-line in Prague, I have submitted a new version of the sessma= tch draft.
 
The major changes are:
 
- An option-tag for the sessmatch extension has been = added.
- A section, describing ALG assumptions, has been add= ed.
- The security considerations section has been modifi= ed.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E142BE6ESESSCMS0356e_-- From ben@nostrum.com Tue May 17 13:43:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9502E078A for ; Tue, 17 May 2011 13:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9nNumVHBM1n for ; Tue, 17 May 2011 13:43:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 78327E0796 for ; Tue, 17 May 2011 13:43:33 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4HKhKGH089005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 May 2011 15:43:27 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-32-940286030 Date: Tue, 17 May 2011 15:43:20 -0500 References: <7F2072F1E0DE894DA4B517B93C6A0585194E142BE6@ESESSCMS0356.eemea.ericsson.se> To: Simple WG Message-Id: <60D56E51-D5AA-4873-BF47-D703904D6E18@nostrum.com> X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Subject: [Simple] Fwd: Draft new version: sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 20:43:34 -0000 --Apple-Mail-32-940286030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as chair) Hi If you commented on version 10, please take a look at version 11 and let = us know if it resolves your comments. Thanks! Ben. Begin forwarded message: > From: Christer Holmberg > Date: May 12, 2011 8:28:32 AM CDT > To: Simple WG > Subject: [Simple] Draft new version: sessmatch-11 >=20 > =20 > Hi, > =20 > Based on the discussions that have taken place on the list, and = off-line in Prague, I have submitted a new version of the sessmatch = draft. > =20 > The major changes are: > =20 > - An option-tag for the sessmatch extension has been added. > - A section, describing ALG assumptions, has been added. > - The security considerations section has been modified. > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-32-940286030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii (as = chair)

Hi

If you commented on = version 10, please take a look at version 11 and let us know if it = resolves your = comments.

Thanks!

Ben.

Begin forwarded message:

From: Christer Holmberg = <christer.holmberg@ericsson.= com>
Date: May 12, 2011 8:28:32 AM CDT
To: Simple WG <simple@ietf.org>
Subject: [Simple] Draft = new version: sessmatch-11

 
Hi,
 
Based on the = discussions that have taken place on the list, and off-line in Prague, I = have submitted a new version of the sessmatch = draft.
 
The major changes are:
 
- An option-tag for = the sessmatch extension has been added.
- A section, describing ALG assumptions, has been = added.
- The security considerations = section has been modified.
 
Regards,
 
Christer
 
_____________________________________= __________
Simple mailing list
Simple@ietf.org
https://www.ietf.org= /mailman/listinfo/simple

= = --Apple-Mail-32-940286030-- From ben@nostrum.com Tue May 17 13:45:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CCAE078A for ; Tue, 17 May 2011 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8xYOxkxo7ykC for ; Tue, 17 May 2011 13:45:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DD9AEE0784 for ; Tue, 17 May 2011 13:45:09 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4HKj5T3089239 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 May 2011 15:45:05 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> Date: Tue, 17 May 2011 15:45:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9CFFCD52-3759-489E-B4FC-AD7B020F3A3E@nostrum.com> References: <1EA75631-ECF8-4CDF-A90D-951CC1B6B841@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Cullen Jennings , Adam Roach , John Mattsson Subject: [Simple] Sessmatch update (was Re: draft-ietf-simple-msrp-sessmatch-10 Issue) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 20:45:11 -0000 (as chair) Please note that Christer published version 11 last week, as a result of = feedback in this thread. If you commented on the previous version, = please let us know as soon as possible if version 11 addresses your = feedback. Thanks! Ben. On Apr 5, 2011, at 4:23 PM, Ben Campbell wrote: > Hi, >=20 > A small group (Christer, Cullen, Adam, Hadriel, John, and myself) held = a face-to-face discussion of issues related to = draft-ietf-simple-msrp-sessmatch-10. The discussion highlighted a = backwards compatibility issue. >=20 > Specifically, an MSRP user agent implementing the sessmatch = description that is behind an SBC or ALG that operates as the draft = envisions cannot interoperate with a peer that uses an MSRP Relay as = defined in RFC 4976. The issue is not caused by the sessmatch extension = per se, but by the SBC/ALG. However, the sole purpose of this extension = is to allow such behavior. >=20 > We agreed that this was a backwards compatibility issue, and as such = would not be acceptable without some negotiation mechanism. >=20 > We discussed the following options. Note that no one option was = favored by all present--I will let people speak individually as to their = preferences. >=20 > 1) Treat MSRP over ALGs using the sessmatch extension as a = fundamentally different protocol from base MSRP >=20 > 2) Create a SIP option tag that indicates that a UA both supports = sessmatch, and does not use an MSRP relay. >=20 > 3) Give up on sessmatch, and assert that for an ALG or SBC to relay = MSRP, it must rewrite the MSRP header fields in a manner similar to an = MSRP Relay. >=20 > The chairs would appreciate a quick resolution to this issue, and = request anyone who cares please make their opinions known on the SIMPLE = list as soon as possible. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Sun May 22 11:57:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF105E0696 for ; Sun, 22 May 2011 11:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlHUz6+E-1MZ for ; Sun, 22 May 2011 11:57:08 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5CF6E0682 for ; Sun, 22 May 2011 11:57:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so667432qyk.10 for ; Sun, 22 May 2011 11:57:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr1115964qci.209.1306090627039; Sun, 22 May 2011 11:57:07 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Sun, 22 May 2011 11:57:06 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 22 May 2011 20:57:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 18:57:09 -0000 2011/4/14 Christer Holmberg : > =C2=A0NOTE: The reason for omitting the 'sessmatch' option-tag is to prov= ide > =C2=A0backward compability in networks where the MSRP entities are based = on > =C2=A0an earlier version of the sessmatch specification, in which usage o= f > =C2=A0the option-tag was not defined. Hi, I don't fully understand why a draft should be backward compliant with a previous version of the same draft. Bad luck if there are commercial products implementing a previous version of the draft. Nobody should trade products based on a changing specification (when it's still a draft). Just wondering. Thanks for any comment or explanation. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sun May 22 12:45:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0BE0695 for ; Sun, 22 May 2011 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8lQNIVcP2YD for ; Sun, 22 May 2011 12:45:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C9177E0651 for ; Sun, 22 May 2011 12:45:24 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c3-4dd9644de5a9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.B0.20773.D4469DD4; Sun, 22 May 2011 21:30:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Sun, 22 May 2011 21:30:21 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Sun, 22 May 2011 21:26:06 +0200 Thread-Topic: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] Thread-Index: AcwYsg4/zYOHc0ULQkaO1x4OYw1WAgABApbR Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3B9@ESESSCMS0356.eemea.ericsson.se> References: <42C57E6F-B75F-4D12-991F-246E3FF31192@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851948F0B38A@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Sessmatch: Proposed option-tag text [was: draft-ietf-simple-msrp-sessmatch-10 Issue] X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 19:45:26 -0000 Hi, >>NOTE: The reason for omitting the 'sessmatch' option-tag is to provide >>backward compability in networks where the MSRP entities are based on >>an earlier version of the sessmatch specification, in which usage of >>the option-tag was not defined. > >Hi, I don't fully understand why a draft should be backward compliant >with a previous version of the same draft. > >Bad luck if there are commercial products implementing a previous >version of the draft. Nobody should trade products based on a changing >specification (when it's still a draft). I agree. But, sometimes it takes a (too) long time to finish a draft. Anyway, the note has been removed from the latest version of the draft, tha= t I submitted a while ago. Regards, Christer= From ben@nostrum.com Mon May 23 09:27:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A536E07AD for ; Mon, 23 May 2011 09:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4QPkHEkFXxvN for ; Mon, 23 May 2011 09:27:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C4C95E07AC for ; Mon, 23 May 2011 09:27:07 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4NFpCRT054736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 10:51:12 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 10:51:11 -0500 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org, "simple-chairs@tools.ietf.org Chairs" Subject: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 16:27:08 -0000 This is a Working Group Last Call of = draft-ietf-simple-msrp-sessmatch-11: http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11 Please note that this draft contains substantial new text since version = 10, primarily concerning the use of an option tag. Even if you were = happy with version 10, please review this version. The WGLC will conclude on 6 June 2011. Please send your comments, = including nits and "this is ready to go" type comments, to the authors = and the working group list. Thanks! Ben.=20= From ben@nostrum.com Mon May 23 14:38:48 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D42E0867 for ; Mon, 23 May 2011 14:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih8r55QuR1Dc for ; Mon, 23 May 2011 14:38:47 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF5E079C for ; Mon, 23 May 2011 14:38:46 -0700 (PDT) Received: from dn3-227.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4NLchrT085642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 May 2011 16:38:44 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 23 May 2011 16:38:43 -0500 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org Subject: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2011 21:38:48 -0000 (as individual) Here are my WGLC comments on sessmatch-11: Major Issues: -- This draft adds an option tag to address backwards compatibility = issues. I am concerned, however, about the guidance to put the tag in a = Requires header "if an entity is performing MSRP related procedures that = require the remote MSRP entity to support the sessmatch extension in = order to enable MSRP media" Putting "sessmatch" in an Requires header = means you aren't willing to talk to someone who uses an RFC4976 relay. = If we see that used heavily, then we have effectively split the = community into camps that can't talk to each other. I don't think we = want to encourage that. I'd at least like to see some text encouraging = implementations to try to find some way to talk to each other, whether = by putting ALGs into an MSRP b2bua mode, reissuing a request without the = Require tag, invoking a relay, etc. Minor Issues: -- general: Keep in mind that RFC 4975 is technically not SIP specific. = MSRP could conceivably be used with other signaling protocols. (Yes, I = realize it probably _won't_). We probably out to mention somewhere = (maybe in the applicability statement) that the option tag usage = described here is specific to SIP, and that if sessmatch is to be used = with any other signaling protocol, then the extension mechanism in that = protocol should be used to indicate support. And that the specifics are = out of scope for this draft. -- section 4.2, last paragraph: "request with a 481 response. The entity = MUST also check to make sure the session is not already in use on = another connection. If the session is already in use, it MUST reject the = request with a 506 response." This is normal 4975 behavior. Is there a need to repeat it here? -- section 4.3, 2nd paragraph: "...located behind an MSRP relay..." We need to better define what "behind a relay" means. I think we a = talking about when an endpoint explicitly authorizes with a relay and = would ordinarily put the relay URI in the SDP path attribute, right? -- same paragraph: "If at least one reliably sent successful response to = the intial INVITE request contains the =92sessmatch=92 option-tag in the = Supported header..." I'm not sure telling the UAS to put the tag in Supported is the right = thing to do to indicate support. It seems like one would either put it = in Required, or just not mention it. If we need the UAC behavior (and = any ALG, etc) to change based on whether or not the UAS expresses = support, then you probably want the UAS to put the tag in a Requires = header, to indicate it plans to invoke the extension. -- section 4.3, 2nd to last paragraph: Do we need some similar text describing the behavior of the UAS if it = requires sessmatch but got an invite without the sessmatch tag in = Supported? -- section 4.3, last paragraph: This "note", combined with the previous paragraph, suggests that an = intermediary MUST in certain circumstances add a tag to a Require = header. How do we expect the UAC to react if it gets a 420 response due = to a Require tag that it didn't actually insert? (i.e. an intermediary = inserted it).=20 -- section 6.3, 2nd to last paragraph (number 2) This makes me nervous without recommending at least some protection of = the SDP, such as SIPS. Editorial Comments: -- Section 1, 4th paragraph: "MSRP entities that support the sessmatch = extension use a different mechanism for matching an MSRP message with an = MSRP session, called session matching." Really, you are matching sessions regardless of whether you follow RFC = 4975 rules vs sessmatch rules. I'm not sure we have to put a "name" on = this--I suggest simply deleting the phrase after the comma. -- section 5.1: "This document does not specify ALG behavior." It sort of does now, if you look at the last 2 paragraphs of 4.3. -- section 5.4: "environments that require SIP identity based = peer-to-peer SDP protection." I would say "environments that use any mechanism for end-to-end = integrity protection of SDP payloads, such as SIP Identity [RFC4474]." -- section 5.5, 2nd paragraph: "ALG relays the MSRP media packages" and = "encrypted MSRP media pacakges" Do you mean packets? -- section 7.1: The formatting is weird in the IANA consideration section. The = description text wraps around. Also, it won't really see encrypted MSRP media packets so much as TLS = packets. It can't tell if those packets actually contain MSRP. -- section 6.2: "It does not however enable a MiTM to monitor TLS = protected MSRP or to in any significant way modify the MSRP = communication content." Does the second clause also refer to TLS protected content?= From christer.holmberg@ericsson.com Mon May 23 23:50:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BCCE0662 for ; Mon, 23 May 2011 23:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RqegQXmuhbf for ; Mon, 23 May 2011 23:50:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id D0A52E06D1 for ; Mon, 23 May 2011 23:50:01 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ed-4ddb55181c00 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.AC.20773.8155BDD4; Tue, 24 May 2011 08:50:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 24 May 2011 08:49:59 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Tue, 24 May 2011 08:49:58 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments Thread-Index: AcwZkdFj7pk/IZE9QSaV7KtLK3FQ4wAR0A2A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 06:50:02 -0000 Hi Ben,=20 In this e-mail I reply to your major issue. I will reply on your minor/edit= orial comments later. >Here are my WGLC comments on sessmatch-11: >=20 >Major Issues: >=20 >-- This draft adds an option tag to address backwards=20 >compatibility issues. I am concerned, however, about the=20 >guidance to put the tag in a Requires header "if an entity is=20 >performing MSRP related procedures that require the remote=20 >MSRP entity to support the sessmatch extension in order to=20 >enable MSRP media" Putting "sessmatch" in an Requires header=20 >means you aren't willing to talk to someone who uses an=20 >RFC4976 relay. If we see that used heavily, then we have=20 >effectively split the community into camps that can't talk to=20 >each other. I don't think we want to encourage that. I'd at=20 >least like to see some text encouraging implementations to=20 >try to find some way to talk to each other, whether by=20 >putting ALGs into an MSRP b2bua mode, reissuing a request=20 >without the Require tag, invoking a relay, etc. What about adding some text that STRONGLY RECOMMENDS entities to implement = a mechanism that allows fallback (e.g. switching to MSRP B2BUA mode) to RFC= 4975 behavior in case the remote entity does not support (or, isn't able to= use due to a relay) sessmatch, rather than using the Require header field? Regards, Christer From christer.holmberg@ericsson.com Tue May 24 06:20:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42232E0745 for ; Tue, 24 May 2011 06:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.484 X-Spam-Level: X-Spam-Status: No, score=-6.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldNIYIurW02X for ; Tue, 24 May 2011 06:20:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C6CBDE0743 for ; Tue, 24 May 2011 06:20:09 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-fa-4ddbb08869ad Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F7.38.09774.880BBDD4; Tue, 24 May 2011 15:20:08 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 24 May 2011 15:20:04 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Tue, 24 May 2011 15:20:03 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments Thread-Index: AcwZkdFj7pk/IZE9QSaV7KtLK3FQ4wAUTmYA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E216B2B@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:20:11 -0000 =20 Hi Ben, Inline are my replies to your minor/editorial comments. ---------- >Minor Issues: >=20 >-- general: Keep in mind that RFC 4975 is technically not SIP=20 >specific. MSRP could conceivably be used with other signaling=20 >protocols. (Yes, I realize it probably _won't_). We probably=20 >out to mention somewhere (maybe in the applicability=20 >statement) that the option tag usage described here is=20 >specific to SIP, and that if sessmatch is to be used with any=20 >other signaling protocol, then the extension mechanism in=20 >that protocol should be used to indicate support. And that=20 >the specifics are out of scope for this draft. I suggest to add the following new paragraph (copy/pasted XML) to the Appli= cability statement section: "This document defines a SIP option-tag , which is used in SIP messages to indicate, or mandate, support of the sessmatch extensi= on. The establishment of MSRP sessmatch extension sessions using other protocols than SIP is outside the scope of= the specification." ---------- >-- section 4.2, last paragraph: "request with a 481 response.=20 >The entity MUST also check to make sure the session is not=20 >already in use on another connection. If the session is=20 >already in use, it MUST reject the request with a 506 response." >=20 >This is normal 4975 behavior. Is there a need to repeat it here? Well, the text describes the session matching procedure using the sessmatch= extension, and the procedure you refer to happens to be the same as for 49= 75 based session matching. So, personally I think it would be good to keep the text. Of course, if you think it would become more clear, I could add the followi= ng to the beginning of the sentence: "Similar to the procedures defined in RFC 4975, if no match exist..." ---------- >-- section 4.3, 2nd paragraph: "...located behind an MSRP relay..." >=20 >We need to better define what "behind a relay" means. I think=20 >we a talking about when an endpoint explicitly authorizes=20 >with a relay and would ordinarily put the relay URI in the=20 >SDP path attribute, right? Yes. Could we maybe instead say "...does not use an MSRP relay for MSRP communic= ation..."? "An MSRP entity that supports the sessmatch extension, and does not use an= MSRP=20 relay for MSRP communication, MUST insert the 'sessmatch' option-tag in th= e Supported=20 header field of the initial INVITE request for a session that contains MSR= P media. " ---------- =20 > -- same paragraph: "If at least one reliably sent successful=20 > response to the intial INVITE request contains the=20 > 'sessmatch' option-tag in the Supported header..." >=20 > I'm not sure telling the UAS to put the tag in Supported is=20 > the right thing to do to indicate support. It seems like one=20 > would either put it in Required, or just not mention it. If=20 > we need the UAC behavior (and any ALG, etc) to change based=20 > on whether or not the UAS expresses support, then you=20 > probably want the UAS to put the tag in a Requires header, to=20 > indicate it plans to invoke the extension. I can change header field from Supported to Require: "If at least one reliably sent successful response to the intial INVITE re= quest contains the 'sessmatch' option-tag in the Require header field of the response, the= MSRP entity MUST=20 use the session matching procedures defined in this specification during t= he session." ---------- > -- section 4.3, 2nd to last paragraph: >=20 > Do we need some similar text describing the behavior of the=20 > UAS if it requires sessmatch but got an invite without the=20 > sessmatch tag in Supported? I guess we could say the following: "If an MSRP entity that supports the sessmatch extension receives an initial INVITE request that does not contain the 'sessmatch' option-tag= in the Supported or Require header field of the request, it MUST NOT inser= t=20 the 'sessmatch' option-tag in the Require header field of any response to = the intial=20 INVITE request, and it MUST NOT use the session matching procedures define= d in this specification during the session" ---------- > -- section 4.3, last paragraph: >=20 > This "note", combined with the previous paragraph, suggests=20 > that an intermediary MUST in certain circumstances add a tag=20 > to a Require header. How do we expect the UAC to react if it=20 > gets a 420 response due to a Require tag that it didn't=20 > actually insert? (i.e. an intermediary inserted it).=20 I don't think that should be a problem, as this can happen only to an UAC t= hat supports the sessmatch extension. Also, based on my reply to your major comment, if we strongly recommend to = not use the Require header field in the first place, this hopefully won't h= appen very often. ---------- >-- section 6.3, 2nd to last paragraph (number 2) >=20 >This makes me nervous without recommending at least some=20 >protection of the SDP, such as SIPS. I suggest to modify, with some restructuring, the following paragraphs as f= ollows: If MSRP endpoints that support the sessmatch extension do not support a= common TLS authentication method based on a pre-shared secret, and neither MSRP endpoint use an MSRP relay for MSRP communication, they SHALL perform=20 TLS authenctication as defined in RFC 4975, which will succeed if there=20 are no ALGs in the MSRP path. =20 If TLS authentication as defined in RFC 4975 fails, an MSRP=20 endpoint that supports the sessmatch extension SHALL either: =20 1) Consider the TLS autentication as failed, in accordance with RFC 497= 5, or 2) If the SIP signalling between the endpoints is protected through e.g.=20 SIPS, and when support of the sessmatch extension is indicated in a = request or response received from the other MSRP endpoint, use fingerprint based authentication without requiring SDP end-to-end integrity, a= nd=20 thus trust the network entities in the signaling path for SDP integrity= . NOTE: As defined in RFC 4975, if TLS autentication fails, the user need= to be able to decide whether to try to establish an MSRP connection without T= LS protection. ---------- > Editorial Comments: >=20 > -- Section 1, 4th paragraph: "MSRP entities that support the=20 > sessmatch extension use a different mechanism for matching an=20 > MSRP message with an MSRP session, called session matching." >=20 > Really, you are matching sessions regardless of whether you=20 > follow RFC 4975 rules vs sessmatch rules. I'm not sure we=20 > have to put a "name" on this--I suggest simply deleting the=20 > phrase after the comma. Will do. ---------- >-- section 5.1: "This document does not specify ALG behavior." >=20 >It sort of does now, if you look at the last 2 paragraphs of 4.3. Well, it's not explicit ALG behavior, eventhough I agree it will be enabled= by ALGs. Maybe we could say something like: "This document does not specify explicit ALG behavior, eventhough some of = the=20 procedures will be enabled by ALGs. However, as the main reason behind the= =20 sessmatch extension is to allow MSRP entities to communicate in networks w= here=20 ALGs are present, this document makes certain assumptions regarding to how= such=20 ALGs behave." ---------- > -- section 5.4: "environments that require SIP identity based=20 > peer-to-peer SDP protection." >=20 > I would say "environments that use any mechanism for=20 > end-to-end integrity protection of SDP payloads, such as SIP=20 > Identity [RFC4474]." Ok. ---------- > -- section 5.5, 2nd paragraph: "ALG relays the MSRP media=20 > packages" and "encrypted MSRP media pacakges" >=20 > Do you mean packets? Yes. I will change to "packets". ---------- =20 > -- section 7.1: >=20 > The formatting is weird in the IANA consideration section.=20 > The description text wraps around. I am not sure I understand. It looks fine to me :) However, based on other comments, I think we have to change the last senten= ce of the Description: "When present in a Require header field, it indicates that the reciving UA= MUST support the session matching mechanism." ---------- >Also, it won't really see encrypted MSRP media packets so=20 >much as TLS packets. It can't tell if those packets actually=20 >contain MSRP. I assume this is a follow up comment on your comment on section 6.2 (below)= ? I will address this in my suggested text below. ---------- > -- section 6.2: "It does not however enable a MiTM to monitor=20 > TLS protected MSRP or to in any significant way modify the=20 > MSRP communication content." >=20 > Does the second clause also refer to TLS protected content? Yes. I suggest the following modified sentence: "It does not however enable a MiTM to monitor TLS protected MSRP, in any significant way modify TLS=20 protected MSRP content or even find out that the packets contain MSRP messages." ---------- Thank You very much for Your comments! Regards, Christer From ben@nostrum.com Tue May 24 06:50:10 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD56E06BA for ; Tue, 24 May 2011 06:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1tcv0d+kmmk for ; Tue, 24 May 2011 06:50:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADEFE06AF for ; Tue, 24 May 2011 06:50:09 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4ODo4VL073056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 May 2011 08:50:04 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 24 May 2011 08:50:04 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <66272D27-CE2A-41D4-8347-69AD83AE3833@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 13:50:10 -0000 On May 24, 2011, at 1:49 AM, Christer Holmberg wrote: >=20 > Hi Ben,=20 >=20 > In this e-mail I reply to your major issue. I will reply on your = minor/editorial comments later. >=20 >> Here are my WGLC comments on sessmatch-11: >>=20 >> Major Issues: >>=20 >> -- This draft adds an option tag to address backwards=20 >> compatibility issues. I am concerned, however, about the=20 >> guidance to put the tag in a Requires header "if an entity is=20 >> performing MSRP related procedures that require the remote=20 >> MSRP entity to support the sessmatch extension in order to=20 >> enable MSRP media" Putting "sessmatch" in an Requires header=20 >> means you aren't willing to talk to someone who uses an=20 >> RFC4976 relay. If we see that used heavily, then we have=20 >> effectively split the community into camps that can't talk to=20 >> each other. I don't think we want to encourage that. I'd at=20 >> least like to see some text encouraging implementations to=20 >> try to find some way to talk to each other, whether by=20 >> putting ALGs into an MSRP b2bua mode, reissuing a request=20 >> without the Require tag, invoking a relay, etc. >=20 > What about adding some text that STRONGLY RECOMMENDS entities to = implement a mechanism that allows fallback (e.g. switching to MSRP B2BUA = mode) to RFC4975 behavior in case the remote entity does not support = (or, isn't able to use due to a relay) sessmatch, rather than using the = Require header field? >=20 That would help.=20 Some of the text in RFC 3261 concerning the 421 response code might be a = good example, as it recommends against its use for similar reasons. (I'm = rather surprised that 3261 didn't have similar language around the = Require header, since it has similar properties). > Regards, >=20 > Christer From adam@nostrum.com Tue May 24 08:10:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E98BE06ED for ; Tue, 24 May 2011 08:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqDRIDBJ+FKi for ; Tue, 24 May 2011 08:10:26 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2F669E075C for ; Tue, 24 May 2011 08:10:25 -0700 (PDT) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4OFALtb080171 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 24 May 2011 10:10:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DDBCA5D.5070104@nostrum.com> Date: Tue, 24 May 2011 10:10:21 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:10:31 -0000 On 5/24/11 01:49, May 24, Christer Holmberg wrote: > What about adding some text that STRONGLY RECOMMENDS entities to > implement a mechanism that allows fallback (e.g. switching to MSRP > B2BUA mode) to RFC4975 behavior in case the remote entity does not > support (or, isn't able to use due to a relay) sessmatch, rather than > using the Require header field? So, to be clear, you're proposing that these intermediaries would not insert a Require header field at all, and instead fall back to being an MSRP B2BUA if the INVITE or its response doesn't indicate support? That seems a reasonable path forward. /a From christer.holmberg@ericsson.com Tue May 24 08:44:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04378E075D for ; Tue, 24 May 2011 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.496 X-Spam-Level: X-Spam-Status: No, score=-6.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OysGU6XpPzS3 for ; Tue, 24 May 2011 08:44:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BCE0730 for ; Tue, 24 May 2011 08:44:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-62-4ddbd26ce259 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 17.88.09774.C62DBDD4; Tue, 24 May 2011 17:44:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 24 May 2011 17:44:44 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 24 May 2011 17:44:43 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments Thread-Index: AcwaJLWBdcg5NINySEei9Gp247675wAAynrQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E216C5B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> <4DDBCA5D.5070104@nostrum.com> In-Reply-To: <4DDBCA5D.5070104@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 15:44:47 -0000 Hi,=20 >>What about adding some text that STRONGLY RECOMMENDS entities to=20 >>implement a mechanism that allows fallback (e.g. switching to MSRP=20 >>B2BUA mode) to RFC4975 behavior in case the remote entity does not=20 >>support (or, isn't able to use due to a relay) sessmatch,=20 >>rather than using the Require header field? >=20 >So, to be clear, you're proposing that these intermediaries=20 >would not insert a Require header field at all, and instead=20 >fall back to being an MSRP B2BUA if the INVITE or its=20 >response doesn't indicate support? That seems a reasonable=20 >path forward. Yes.=20 That is just an example, though. I don't think we should mandate it. Regards, Christer From ben@nostrum.com Tue May 24 12:42:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1B6E0719 for ; Tue, 24 May 2011 12:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWymnzwIkWPu for ; Tue, 24 May 2011 12:42:33 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 26707E06A5 for ; Tue, 24 May 2011 12:42:31 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4OJgPI4004609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 May 2011 14:42:27 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E216B2B@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 24 May 2011 14:42:25 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E216B2B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism) Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:42:34 -0000 On May 24, 2011, at 8:20 AM, Christer Holmberg wrote: >=20 > Hi Ben, >=20 > Inline are my replies to your minor/editorial comments. >=20 >=20 > ---------- >=20 >=20 >> Minor Issues: >>=20 >> -- general: Keep in mind that RFC 4975 is technically not SIP=20 >> specific. MSRP could conceivably be used with other signaling=20 >> protocols. (Yes, I realize it probably _won't_). We probably=20 >> out to mention somewhere (maybe in the applicability=20 >> statement) that the option tag usage described here is=20 >> specific to SIP, and that if sessmatch is to be used with any=20 >> other signaling protocol, then the extension mechanism in=20 >> that protocol should be used to indicate support. And that=20 >> the specifics are out of scope for this draft. >=20 > I suggest to add the following new paragraph (copy/pasted XML) to the = Applicability statement section: >=20 > "This document defines a SIP option-tag , which is used > in SIP messages to indicate, or mandate, support of the = sessmatch extension. The establishment of MSRP sessmatch > extension sessions using other protocols than SIP is = outside the scope of the specification." Works for me. >=20 > ---------- >=20 >=20 >> -- section 4.2, last paragraph: "request with a 481 response.=20 >> The entity MUST also check to make sure the session is not=20 >> already in use on another connection. If the session is=20 >> already in use, it MUST reject the request with a 506 response." >>=20 >> This is normal 4975 behavior. Is there a need to repeat it here? >=20 > Well, the text describes the session matching procedure using the = sessmatch extension, and the procedure you refer to happens to be the = same as for 4975 based session matching. >=20 > So, personally I think it would be good to keep the text. >=20 > Of course, if you think it would become more clear, I could add the = following to the beginning of the sentence: >=20 > "Similar to the procedures defined in RFC 4975, if no match = exist..." Works for me. >=20 >=20 > ---------- >=20 >=20 >> -- section 4.3, 2nd paragraph: "...located behind an MSRP relay..." >>=20 >> We need to better define what "behind a relay" means. I think=20 >> we a talking about when an endpoint explicitly authorizes=20 >> with a relay and would ordinarily put the relay URI in the=20 >> SDP path attribute, right? >=20 > Yes. >=20 > Could we maybe instead say "...does not use an MSRP relay for MSRP = communication..."? >=20 > "An MSRP entity that supports the sessmatch extension, and does = not use an MSRP=20 > relay for MSRP communication, MUST insert the 'sessmatch' = option-tag in the Supported=20 > header field of the initial INVITE request for a session that = contains MSRP media. " I think this mostly works. My only question is whether we want to say = anything about how an endpoint that does not use an MSRP relay will only = put one URI in the path attribute--or more strongly, an endpoint using = the sessmatch extension MUST NOT insert more than one URI in the path = attribute. >=20 >=20 > ---------- >=20 >=20 >> -- same paragraph: "If at least one reliably sent successful=20 >> response to the intial INVITE request contains the=20 >> 'sessmatch' option-tag in the Supported header..." >>=20 >> I'm not sure telling the UAS to put the tag in Supported is=20 >> the right thing to do to indicate support. It seems like one=20 >> would either put it in Required, or just not mention it. If=20 >> we need the UAC behavior (and any ALG, etc) to change based=20 >> on whether or not the UAS expresses support, then you=20 >> probably want the UAS to put the tag in a Requires header, to=20 >> indicate it plans to invoke the extension. >=20 > I can change header field from Supported to Require: >=20 > "If at least one reliably sent successful response to the intial = INVITE request contains the > 'sessmatch' option-tag in the Require header field of the = response, the MSRP entity MUST=20 > use the session matching procedures defined in this = specification during the session." >=20 WFM >=20 > ---------- >=20 >=20 >> -- section 4.3, 2nd to last paragraph: >>=20 >> Do we need some similar text describing the behavior of the=20 >> UAS if it requires sessmatch but got an invite without the=20 >> sessmatch tag in Supported? >=20 > I guess we could say the following: >=20 > "If an MSRP entity that supports the sessmatch extension = receives an > initial INVITE request that does not contain the 'sessmatch' = option-tag in > the Supported or Require header field of the request, it MUST = NOT insert=20 > the 'sessmatch' option-tag in the Require header field of any = response to the intial=20 > INVITE request, and it MUST NOT use the session matching = procedures defined in > this specification during the session" >=20 I was thinking more around the scenario where you have a UAS that can = only communicate using sessmatch, but the UAC doesn't support it. Would = you send a 421? (This would need to be subject to the same caveat about = a UAC putting sessmatch in Require, of course) >=20 > ---------- >=20 >=20 >> -- section 4.3, last paragraph: >>=20 >> This "note", combined with the previous paragraph, suggests=20 >> that an intermediary MUST in certain circumstances add a tag=20 >> to a Require header. How do we expect the UAC to react if it=20 >> gets a 420 response due to a Require tag that it didn't=20 >> actually insert? (i.e. an intermediary inserted it).=20 >=20 >=20 > I don't think that should be a problem, as this can happen only to an = UAC that supports the sessmatch extension. >=20 > Also, based on my reply to your major comment, if we strongly = recommend to not use the Require header field in the first place, this = hopefully won't happen very often. Okay. We might need to be more explicit that the intermediary would only = do this if it was already in Supported. >=20 >=20 > ---------- >=20 >=20 >> -- section 6.3, 2nd to last paragraph (number 2) >>=20 >> This makes me nervous without recommending at least some=20 >> protection of the SDP, such as SIPS. >=20 > I suggest to modify, with some restructuring, the following paragraphs = as follows: >=20 > If MSRP endpoints that support the sessmatch extension do not = support a common TLS > authentication method based on a pre-shared secret, and neither = MSRP > endpoint use an MSRP relay for MSRP communication, they SHALL = perform=20 > TLS authenctication as defined in RFC 4975, which will succeed = if there=20 > are no ALGs in the MSRP path. >=20 > If TLS authentication as defined in RFC 4975 fails, an MSRP=20 > endpoint that supports the sessmatch extension SHALL either: >=20 > 1) Consider the TLS autentication as failed, in accordance with = RFC 4975, or >=20 > 2) If the SIP signalling between the endpoints is protected = through e.g.=20 > SIPS, and when support of the sessmatch extension is = indicated in a request > or response received from the other MSRP endpoint, use = fingerprint > based authentication without requiring SDP end-to-end = integrity, and=20 > thus trust the network entities in the signaling path for SDP = integrity. >=20 > NOTE: As defined in RFC 4975, if TLS autentication fails, the = user need to be > able to decide whether to try to establish an MSRP connection = without TLS protection. I think that helps. (I do expect this section to get a lot of AD = scrutiny, BTW) [...] >=20 >=20 >> -- section 5.1: "This document does not specify ALG behavior." >>=20 >> It sort of does now, if you look at the last 2 paragraphs of 4.3. >=20 > Well, it's not explicit ALG behavior, eventhough I agree it will be = enabled by ALGs. >=20 > Maybe we could say something like: >=20 > "This document does not specify explicit ALG behavior, = eventhough some of the=20 > procedures will be enabled by ALGs. However, as the main reason = behind the=20 > sessmatch extension is to allow MSRP entities to communicate in = networks where=20 > ALGs are present, this document makes certain assumptions = regarding to how such=20 > ALGs behave." >=20 Okay [...] >=20 >> -- section 7.1: >>=20 >> The formatting is weird in the IANA consideration section.=20 >> The description text wraps around. >=20 > I am not sure I understand. It looks fine to me :) In the PDF version, they wrap around. In the plain text and HTML = versions, the lines are just too long. (idnits complains about the line = length) >=20 > However, based on other comments, I think we have to change the last = sentence of the Description: >=20 > "When present in a Require header field, it indicates that the = reciving UA MUST support the session matching mechanism." >=20 >=20 Okay. > ---------- >=20 >=20 >> Also, it won't really see encrypted MSRP media packets so=20 >> much as TLS packets. It can't tell if those packets actually=20 >> contain MSRP. >=20 > I assume this is a follow up comment on your comment on section 6.2 = (below)? Yes, sorry. >=20 > I will address this in my suggested text below. >=20 >=20 > ---------- >=20 >=20 >> -- section 6.2: "It does not however enable a MiTM to monitor=20 >> TLS protected MSRP or to in any significant way modify the=20 >> MSRP communication content." >>=20 >> Does the second clause also refer to TLS protected content? >=20 > Yes. I suggest the following modified sentence: >=20 > "It does not however enable a MiTM to monitor TLS > protected MSRP, in any significant way modify TLS=20 > protected MSRP content or even find out that the > packets contain MSRP messages." WFM From ibc@aliax.net Tue May 24 12:48:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E540E06A5 for ; Tue, 24 May 2011 12:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVhKvRJ9Hru9 for ; Tue, 24 May 2011 12:48:12 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9570E064E for ; Tue, 24 May 2011 12:48:11 -0700 (PDT) Received: by qwc23 with SMTP id 23so5666194qwc.31 for ; Tue, 24 May 2011 12:48:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2355457qcb.285.1306266491057; Tue, 24 May 2011 12:48:11 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 24 May 2011 12:48:11 -0700 (PDT) Date: Tue, 24 May 2011 21:48:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Simple WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 19:48:12 -0000 Hi, I'm trying to understand motivation and rationale for this draft. Please let me know if the following points (those I've understood by reading the text) are correct: 1) This draft is just useful for vendors manufacturing MSRP entities behaving as ALG devices (even if the concept of "ALG" is vaguely defined for SIP) instead of behaving as full B2BUA. These devices (probably IP routers) just want to change/replace some line in the SDP and expect that TCP would do the rest. 2) MSRP mandates TLS (which is good) but this draft breaks TLS name based authentication (and suggests implementing other specifications, some of them still drafts, as alternative). 3) The mechanism proposed in this draft is already adopted by OMA in their specifications for SIP/MSRP over mobile networks. About point 1) Let's suppose I want to build a SIP client implementing MSRP (with support for MSRP protocol and MSRP relays). It should be enough as MSRP relays are supposed to fix NAT issues. But now big vendors arrive and decide that they want to control/monitor/manage all the MSRP sessions. Also they don't want to build MSRP relays (as the clients could avoid them), neither full B2BUA (which are complex/expensive), but just want to force such MSRP inspection at IP/TCP level, so voila: they impose routers with ALG. So now, if I want my SIP UA to interoperate with those ALG devices, I need to implement this draft. Yes, the draft says something about these ALG devices becoming a B2BUA in case they connect with a client not supporting this specification, but let's be honest: do we really expect a MSRP ALG device will become a SIP/MSRP full B2BUA just for these cases? It's easier to force the clients to buy "certificated" SIP/MSRP clients. About point 2) A problem in most of the SIP related specifications is the abuse of MAY and COULD words, so finally each implementor gets his own interpretation. MSRP RFC, however, mandates (SHOULD) the usage of TLS (TCP is for debugging purposes). This is good, very good. But now this draft makes it difficult, just to satisfy vendors of intermediary MSRP entities. Is it a good standardization decision? In conclusion (just my conclusion): Advantages of this draft ---------------------------------- - For big vendors: - ALG routers are cheaper than full MSRP relays or full B2BUA (for SIP and MSRP). - They can control/monitor/inspect users's MSRP traffic (as it's done at IP/TCP level) and UA's cannot avoid them. - For SIP&MSRP UA's developers: - No advantages. - For final users: - No advantages. Disadvantages of this draft --------------------------------------- - For big vendors: - No disadvantage. - For SIP&MSRP UA's developers: - Must implement this draft to interoperate with vendors implementing it. - Broken TLS name authentication (or invest long time and resources implementing supposed alternatives). - For final users: - Must buy/get a UA supporting this specification. Honestly I cannot understand how this draft exists. SIP and MSRP work on top of the transport layer so if a vendor wants to play with my MSRP traffic it should at least work at SIP/MSRP level (this is: build a full SIP/MSRP B2BUA and don't bother the rest of SIP/MSRP devices and implementors). Just my opinion. Best regards. --=20 I=C3=B1aki Baz Castillo From wwwrun@ietfa.amsl.com Tue May 24 13:32:17 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 3F39DE069D; Tue, 24 May 2011 13:32:17 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@ietfa.amsl.com, Context@ietfa.amsl.com (SNMP), EngineID@ietfa.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110524203217.3F39DE069D@ietfa.amsl.com> Date: Tue, 24 May 2011 13:32:17 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 20:32:17 -0000 'State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From ag@ag-projects.com Tue May 24 15:17:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6655EE0670 for ; Tue, 24 May 2011 15:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-ye7Ht6D9b3 for ; Tue, 24 May 2011 15:17:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4D683E07E5 for ; Tue, 24 May 2011 15:17:21 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A2D8AB01C2; Wed, 25 May 2011 00:17:19 +0200 (CEST) Received: from [192.168.1.122] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id DF2F3B017D for ; Wed, 25 May 2011 00:17:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: Date: Wed, 25 May 2011 00:17:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: [Simple] draft-ietf-simple-sessmatch is a horrible hack X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 22:17:24 -0000 Hello, My comment about this draft is: This drafts describes a horrible hack for how to render an otherwise = well designed protocol useless. It is an absolute shame to make a = standard out of it. By letting this draft become a standard, the interoperability of SIP = applications beyond VoIP will be completely broken as developers will = not be able to navigate through the exceptions and broken assumptions = implied by the proposed mechanism. All security and integrity properties = of MSRP protocol become useless by doing it just because some clueless = people mentioned it in the past in an OMA document which is full of = broken assumptions, this one included. This "thing" should not have = never been an MSRP related document at all, it should have described a = complete different protocol all together so that people do not get = confused by it. I have implemented all SIMPLE WG related MSRP specifications to date and = everything made sense until this draft showed up. This does not make = sense. This is a horrible way for SIMPLE WG to complete its agenda after having = produced an excellent suite of MSRP standards. Best regards, Adrian From fluffy@cisco.com Tue May 24 17:29:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33503E06F4 for ; Tue, 24 May 2011 17:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.063 X-Spam-Level: X-Spam-Status: No, score=-110.063 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-XKO6CtZ07K for ; Tue, 24 May 2011 17:29:55 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5DAE06D7 for ; Tue, 24 May 2011 17:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4389; q=dns/txt; s=iport; t=1306283395; x=1307492995; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zy4gR8iH3m8YxnG+BMHfr8uWyU0wKYrdRQEyZooFccY=; b=gKxXmPIi86MllFGP03qvhCMxGrGulZlF1FGOH0gNGCq7/7ffvECTK4/4 eAxtkwc92Xqqs0FuTIaA1+Df4Ys9PW0SHYIaDfHybKDhXRRRoMync0gbN sbqaqpbW5NsmJuAWZeD6b+OSAexGMEIrJ2p5Yn5k5p+84+qaQB5SUrHZ6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADVN3E2rRDoJ/2dsb2JhbACmKXeIcKEXnXGGHASGWYlOhDSKbw X-IronPort-AV: E=Sophos;i="4.65,264,1304294400"; d="scan'208";a="322864661" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-3.cisco.com with ESMTP; 25 May 2011 00:29:54 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4P0TrvU003648; Wed, 25 May 2011 00:29:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Tue, 24 May 2011 18:29:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 00:29:56 -0000 I had promised myself not to spend more time on this whole topic but = reading your Adrian's comments made me laugh so hard that I that once = again I will make the mistake of replying. I predict the text that is = being added to allow for this to interoperate with MSRP endpoint or to = mitigate the security breakage will be ignored by 100% of people that = implement the draft. The gains over just doing and SBC seem shockingly = small given the breakage introduced.=20 On May 24, 2011, at 1:48 PM, I=F1aki Baz Castillo wrote: > Hi, I'm trying to understand motivation and rationale for this draft. > Please let me know if the following points (those I've understood by > reading the text) are correct: >=20 > 1) This draft is just useful for vendors manufacturing MSRP entities > behaving as ALG devices (even if the concept of "ALG" is vaguely > defined for SIP) instead of behaving as full B2BUA. These devices > (probably IP routers) just want to change/replace some line in the SDP > and expect that TCP would do the rest. >=20 > 2) MSRP mandates TLS (which is good) but this draft breaks TLS name > based authentication (and suggests implementing other specifications, > some of them still drafts, as alternative). >=20 > 3) The mechanism proposed in this draft is already adopted by OMA in > their specifications for SIP/MSRP over mobile networks. >=20 >=20 >=20 > About point 1) >=20 > Let's suppose I want to build a SIP client implementing MSRP (with > support for MSRP protocol and MSRP relays). It should be enough as > MSRP relays are supposed to fix NAT issues. But now big vendors arrive > and decide that they want to control/monitor/manage all the MSRP > sessions. Also they don't want to build MSRP relays (as the clients > could avoid them), neither full B2BUA (which are complex/expensive), > but just want to force such MSRP inspection at IP/TCP level, so voila: > they impose routers with ALG. >=20 > So now, if I want my SIP UA to interoperate with those ALG devices, I > need to implement this draft. Yes, the draft says something about > these ALG devices becoming a B2BUA in case they connect with a client > not supporting this specification, but let's be honest: do we really > expect a MSRP ALG device will become a SIP/MSRP full B2BUA just for > these cases? It's easier to force the clients to buy "certificated" > SIP/MSRP clients. >=20 >=20 > About point 2) >=20 > A problem in most of the SIP related specifications is the abuse of > MAY and COULD words, so finally each implementor gets his own > interpretation. MSRP RFC, however, mandates (SHOULD) the usage of TLS > (TCP is for debugging purposes). This is good, very good. But now this > draft makes it difficult, just to satisfy vendors of intermediary MSRP > entities. Is it a good standardization decision? >=20 >=20 >=20 >=20 > In conclusion (just my conclusion): >=20 >=20 > Advantages of this draft > ---------------------------------- >=20 > - For big vendors: > - ALG routers are cheaper than full MSRP relays or full B2BUA (for > SIP and MSRP). > - They can control/monitor/inspect users's MSRP traffic (as it's > done at IP/TCP level) > and UA's cannot avoid them. >=20 > - For SIP&MSRP UA's developers: > - No advantages. >=20 > - For final users: > - No advantages. >=20 >=20 > Disadvantages of this draft > --------------------------------------- >=20 > - For big vendors: > - No disadvantage. >=20 > - For SIP&MSRP UA's developers: > - Must implement this draft to interoperate with vendors implementing = it. > - Broken TLS name authentication (or invest long time and resources > implementing > supposed alternatives). >=20 > - For final users: > - Must buy/get a UA supporting this specification. >=20 >=20 > Honestly I cannot understand how this draft exists. SIP and MSRP work > on top of the transport layer so if a vendor wants to play with my > MSRP traffic it should at least work at SIP/MSRP level (this is: build > a full SIP/MSRP B2BUA and don't bother the rest of SIP/MSRP devices > and implementors). >=20 > Just my opinion. Best regards. >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From shida@ntt-at.com Tue May 24 22:28:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1CBE0706 for ; Tue, 24 May 2011 22:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVypSYA1ff70 for ; Tue, 24 May 2011 22:28:22 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id DC026E0699 for ; Tue, 24 May 2011 22:28:20 -0700 (PDT) Received: from [122.133.118.179] (port=54720 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QP6dk-00072L-C8; Wed, 25 May 2011 00:28:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 25 May 2011 14:28:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <80F44E0A-D0C7-4F41-9A13-5B48963AC174@ntt-at.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194E216B2B@ESESSCMS0356.eemea.ericsson.se> To: Ben Campbell X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-122-133-118-179.tky.mesh.ad.jp ([192.168.1.4]) [122.133.118.179]:54720 X-Source-Auth: shida@agnada.com X-Email-Count: 0 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" , Simple WG Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:28:22 -0000 My comments inline. >>> -- same paragraph: "If at least one reliably sent successful=20 >>> response to the intial INVITE request contains the=20 >>> 'sessmatch' option-tag in the Supported header..." >>>=20 >>> I'm not sure telling the UAS to put the tag in Supported is=20 >>> the right thing to do to indicate support. It seems like one=20 >>> would either put it in Required, or just not mention it. If=20 >>> we need the UAC behavior (and any ALG, etc) to change based=20 >>> on whether or not the UAS expresses support, then you=20 >>> probably want the UAS to put the tag in a Requires header, to=20 >>> indicate it plans to invoke the extension. >>=20 >> I can change header field from Supported to Require: >>=20 >> "If at least one reliably sent successful response to the intial = INVITE request contains the >> 'sessmatch' option-tag in the Require header field of the = response, the MSRP entity MUST=20 >> use the session matching procedures defined in this = specification during the session." >>=20 >=20 > WFM I think UAS sending the option-tag in Supported is fine, I don't=20 know why we should only set it to Require header. Is this for=20 when UAS is aware of ALG being on the path which mocks with=20 the SDP, mandating the use of sessmatch? If so I think we should=20 be explicit about that. =20 Whether the scenario exists or not, there well can be a scenario=20 where ALG which mocks with the SDP doesn't exists. Making it=20 unnecessary to use sessmatch. Furthermore, if we go ahead=20 with always setting the sessmatch in Require in response from UAS,=20 if UAC doesn't support it but ALG is not present, MSRP session that=20 COULD have been established will not establish. =20 >=20 >>=20 >> ---------- >>=20 >>=20 >>> -- section 4.3, 2nd to last paragraph: >>>=20 >>> Do we need some similar text describing the behavior of the=20 >>> UAS if it requires sessmatch but got an invite without the=20 >>> sessmatch tag in Supported? >>=20 >> I guess we could say the following: >>=20 >> "If an MSRP entity that supports the sessmatch extension = receives an >> initial INVITE request that does not contain the 'sessmatch' = option-tag in >> the Supported or Require header field of the request, it MUST = NOT insert=20 >> the 'sessmatch' option-tag in the Require header field of any = response to the intial=20 >> INVITE request, and it MUST NOT use the session matching = procedures defined in >> this specification during the session" >>=20 >=20 > I was thinking more around the scenario where you have a UAS that can = only communicate using sessmatch, but the UAC doesn't support it. Would = you send a 421? (This would need to be subject to the same caveat about = a UAC putting sessmatch in Require, of course) I think we should say that UA supporting the specification=20 MUST always insert the "sessmatch" option tag whether it is=20 behind the MSRP relay or not. It takes out the guesswork by=20 the UAS. I think putting sessmatch in Require should only be encouraged=20 when UAC or UAS is aware of ALG(s) that mocks with SDP and=20 it knows there is no MSRP relays that it can use, mandating the=20 use of sessmatch for successfully establishing MSRP session.=20 If there is no ALG and no MSRP relay, MSRP should work just=20 fine right? So why fail it with 421 when one doesn't support the=20 mechanism that may not be necessary in some situation? Regards Shida From shida@ntt-at.com Tue May 24 22:57:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA46713000A for ; Tue, 24 May 2011 22:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVlyZGidk-zb for ; Tue, 24 May 2011 22:57:12 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 46F02E07B2 for ; Tue, 24 May 2011 22:57:12 -0700 (PDT) Received: from [122.133.118.179] (port=54902 helo=[192.168.1.4]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QP75i-0000YS-Sd; Wed, 25 May 2011 00:57:11 -0500 From: Shida Schubert Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2011 14:57:09 +0900 Message-Id: To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-122-133-118-179.tky.mesh.ad.jp ([192.168.1.4]) [122.133.118.179]:54902 X-Source-Auth: shida@agnada.com X-Email-Count: 0 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:57:13 -0000 I have read the previous draft and had no issues with the previous = draft but=20 I have re-reviewed the draft once again and below are my comments.=20 I only have minor comments and I think the document is ready to = proceed. Minor concern/clarification 1. SIP-identity is used here and there, is it the RFC4744 or something = else? If it is RFC4744, I don't know why it can't be used. If the ALG is = behind the=20 authentication server defined in RFC4744 then SIP-identity should be = able=20 to function.=20 2. There is a mention of option-tag usage in Require in response but=20 there is no mentioning of its use in Require in request. I have no = strong=20 opinion against this, but if it is feasible to use it in response, I = don't see=20 why it wouldn't be the case for request.=20 Nits:=20 =20 1. Abstract remove "of MSRP entities" 2. Abstract add '' to sessmatch after "option-tag, ".=20 3. Introduction OLD : "in order to match an MSRP message to an MSRP session. That = requires consistency between" NEW :"in order to match an MSRP message to an MSRP session, which = requires consistency between" 4. Introduction OLD : "The reason is that the matching of an MSRP message to an = ongoing session will not fail" NEW : "The reason is that the matching of an MSRP message to an ongoing = session will not fail because there is no entity modifying the SDP." 5. Introduction OLD : "MSRP B2BUA functionality, can normally not establish MSRP = sessions" NEW : "MSRP B2BUA functionality, can not normally establish MSRP = sessions" 6. Applicability Statement OLD : "where ALGs that might modify the address information of the SDP = a=3Dpath attribute, but do not implement MSRP B2BUA functionality, are = present." NEW : "where ALGs are present that might modify the address information = of the SDP a=3Dpath attribute, but do not implement MSRP B2BUA = functionality." 7. Session Matching OLD : "and the one defined in this specification for the sessmatch = extension," =20 NEW : "and the one defined in this specification," 8. Session Matching OLD : "while the mechanism in RFC 4975 uses the MSRP URI comparison = rules for " NEW : "while the mechanism in RFC 4975 uses the entire MSRP URI = comparison rules for=20 9. Session Matchin OLD : "If a match exists, the entity MUST assume that the host that = formed the connection is the host to which this URI was given." =20 NEW : "If a match exists, the entity MUST assume that the host that = formed the connection to, is the host to which this URI was given." 10. Session Matching OLD : "The entity MUST also check to make sure the session is not = already " NEW : "The entity MUST also check to make sure the session-id is not = already " 11. Usage of =92sessmatch=92 option-tag OLD : "INVITE request contains the =92sessmatch=92 option-tag in the = Supported header field of the response," NEW : "INVITE request contains the =92sessmatch=92 option-tag in the = Supported header field," 12. Usage of =92sessmatch=92 option-tag OLD : "in order to anchor and forward MSRP traffic, but will not be = able to perform" NEW : "in order to anchor and forward MSRP traffic, but unable to = perform" 13. Usage of =92sessmatch=92 option-tag OLD : "and therfore sends a 420 (Not Supported) response to the INVITE = request, is outside the scope of this specification." NEW : "and sending a 420 (Not Supported) response to the INVITE = request, is outside the scope of this specification." 14. MSRP awareness The MSRP communication. Is this supposed to be MSRP session?=20 * I forgot the difference between MSRP session and MSRP = communication.. The terminology=20 is used interchangeably throughout the draft. I guess I can look at = the RFC4975 and remind myself of the difference..=20 15. TCP connection reuse OLD : "MSRP payload might not enable re-usage of TCP connections" NEW : "MSRP payload might not enable reuse of TCP connections" 16. Is the Relay extension a Normative reference, shouldn't it be = Informative? Also if the=20 SIP Identity based SDP protection refers to "RFC4474" then I think it = should be added=20 to the reference as well.=20 Regards Shida= From christer.holmberg@ericsson.com Tue May 24 23:45:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D2AE0688 for ; Tue, 24 May 2011 23:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvibrpgbqFse for ; Tue, 24 May 2011 23:45:47 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B6BA3E0678 for ; Tue, 24 May 2011 23:45:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ae-4ddca598a1a8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F2.AC.09774.895ACDD4; Wed, 25 May 2011 08:45:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 08:45:44 +0200 From: Christer Holmberg To: Ben Campbell Date: Wed, 25 May 2011 08:45:43 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments Thread-Index: AcwaSrjSp07Wo1rhTrepemBPLiMjMwAWeXyC Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E216B2B@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's minor/editorial comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 06:45:48 -0000 Hi Ben, Inline are my replies on the issues where you did not indicate "WFM" :) ---------- >>> -- section 4.3, 2nd paragraph: "...located behind an MSRP relay..." >>> >>> We need to better define what "behind a relay" means. I think >>> we a talking about when an endpoint explicitly authorizes >>> with a relay and would ordinarily put the relay URI in the >>> SDP path attribute, right? >> >>Yes. >> >> Could we maybe instead say "...does not use an MSRP relay for MSRP commu= nication..."? >> >> "An MSRP entity that supports the sessmatch extension, and does no= t use an MSRP >> relay for MSRP communication, MUST insert the 'sessmatch' option-t= ag in the Supported >> header field of the initial INVITE request for a session that cont= ains MSRP media. " > >I think this mostly works. My only question is whether we want to say anyt= hing about how an endpoint that=20 >does not use an MSRP relay will only put one URI in the path attribute--or= more strongly, an endpoint using the=20 >sessmatch extension MUST NOT insert more than one URI in the path attribut= e. So, something like: "An MSRP entity that supports the sessmatch extension MUST NOT inser= t more than one URI in the SDP a=3Dpath attribute, as it could make other entities to assume that the entit= y uses an MSRP relay for MSRP communication." ---------- >>> -- section 4.3, 2nd to last paragraph: >>> >>> Do we need some similar text describing the behavior of the >>> UAS if it requires sessmatch but got an invite without the >>> sessmatch tag in Supported? >> >> I guess we could say the following: >> >> "If an MSRP entity that supports the sessmatch extension receives = an >> initial INVITE request that does not contain the 'sessmatch' optio= n-tag in >> the Supported or Require header field of the request, it MUST NOT = insert >> the 'sessmatch' option-tag in the Require header field of any resp= onse to the intial >> INVITE request, and it MUST NOT use the session matching procedure= s defined in >> this specification during the session" >> > >I was thinking more around the scenario where you have a UAS that can only= communicate using sessmatch, but the UAC=20 >doesn't support it. Would you send a 421? (This would need to be subject t= o the same caveat about a UAC putting=20 >sessmatch in Require, of course) Ok, I understand. I don't think the UAS should behave in that way in the first place. As sess= match is an extension to RFC 4975, it means that the UAS must also support = RFC 4975. I can add some wording about that, if needed. But, if the UAS (for whatever reason) doesn't want to use MSRP without sess= match it can either reject the request (e.g. using 421 or 415), or only rej= ect the MSRP part by setting the port to zero. ---------- >>> -- section 4.3, last paragraph: >>> >>> This "note", combined with the previous paragraph, suggests >>> that an intermediary MUST in certain circumstances add a tag >>> to a Require header. How do we expect the UAC to react if it >>> gets a 420 response due to a Require tag that it didn't >>> actually insert? (i.e. an intermediary inserted it). >> >> >>I don't think that should be a problem, as this can happen only to an UAC= that supports the sessmatch extension. >> >>Also, based on my reply to your major comment, if we strongly recommend t= o not use the Require header field in the first place, this hopefully won't= happen very often. > >Okay. We might need to be more explicit that the intermediary would only d= o this if it was already in Supported. That has been my intention, but it may need to be more clear. I'll look int= o it. ---------- >>> -- section 6.3, 2nd to last paragraph (number 2) >>> >>> This makes me nervous without recommending at least some >>> protection of the SDP, such as SIPS. >> >> I suggest to modify, with some restructuring, the following paragraphs a= s follows: >> >> If MSRP endpoints that support the sessmatch extension do not supp= ort a common TLS >> authentication method based on a pre-shared secret, and neither MS= RP >> endpoint use an MSRP relay for MSRP communication, they SHALL perf= orm >> TLS authenctication as defined in RFC 4975, which will succeed if = there >> are no ALGs in the MSRP path. >> >> If TLS authentication as defined in RFC 4975 fails, an MSRP >> endpoint that supports the sessmatch extension SHALL either: >> >> 1) Consider the TLS autentication as failed, in accordance with RF= C 4975, or >> >> 2) If the SIP signalling between the endpoints is protected throug= h e.g. >> SIPS, and when support of the sessmatch extension is indicated = in a request >> or response received from the other MSRP endpoint, use fingerpr= int >> based authentication without requiring SDP end-to-end integrity,= and >> thus trust the network entities in the signaling path for SDP i= ntegrity. >> >> NOTE: As defined in RFC 4975, if TLS autentication fails, the user= need to be >> able to decide whether to try to establish an MSRP connection with= out TLS protection. > >I think that helps. (I do expect this section to get a lot of AD scrutiny,= BTW) I guess so. But, I've done my best to cover the security, and there it not = much more I can do. ---------- >>> -- section 7.1: >>> >>> The formatting is weird in the IANA consideration section. >>> The description text wraps around. >> >> I am not sure I understand. It looks fine to me :) > >In the PDF version, they wrap around. In the plain text and HTML versions,= the lines are just too long. (idnits complains about the line length) Ok, I'll double check it. Once again, thanks for your comments! They were very constructive! Regards, Christer= From christer.holmberg@ericsson.com Wed May 25 00:04:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E070E069A for ; Wed, 25 May 2011 00:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.042 X-Spam-Level: X-Spam-Status: No, score=-6.042 tagged_above=-999 required=5 tests=[AWL=-0.343, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwgVtXl97Mec for ; Wed, 25 May 2011 00:04:50 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AFFC7E0662 for ; Wed, 25 May 2011 00:04:49 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-11-4ddcaa0f3003 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.34.20773.F0AACDD4; Wed, 25 May 2011 09:04:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 09:04:47 +0200 From: Christer Holmberg To: Cullen Jennings , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 09:04:46 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwacuJiJVQj5daATd2iZlWrMyaRzQANgvby Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> References: , <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> In-Reply-To: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 07:04:51 -0000 Cullen, I am deeply sorry for having to interupt your laughing, but if you could ta= ke a few moments to read the following. First, the text is very much based on the discussions we had in Prague - di= scussions that you yourself were part of, and which outcome and way forward= I had the impresstion that your were ok with. If you don't think the text = reflects those discussions, I would be very happy with text proposals on ho= w to correct that. Second, I can inform you that there is at least one (that I am aware of) ve= ndor that plans to implement a "fallback mechanism", for interoperability p= urpose. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Cullen= Jennings [fluffy@cisco.com] Sent: Wednesday, May 25, 2011 3:29 AM To: I=F1aki Baz Castillo Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch I had promised myself not to spend more time on this whole topic but readin= g your Adrian's comments made me laugh so hard that I that once again I wil= l make the mistake of replying. I predict the text that is being added to a= llow for this to interoperate with MSRP endpoint or to mitigate the securit= y breakage will be ignored by 100% of people that implement the draft. The = gains over just doing and SBC seem shockingly small given the breakage intr= oduced. On May 24, 2011, at 1:48 PM, I=F1aki Baz Castillo wrote: > Hi, I'm trying to understand motivation and rationale for this draft. > Please let me know if the following points (those I've understood by > reading the text) are correct: > > 1) This draft is just useful for vendors manufacturing MSRP entities > behaving as ALG devices (even if the concept of "ALG" is vaguely > defined for SIP) instead of behaving as full B2BUA. These devices > (probably IP routers) just want to change/replace some line in the SDP > and expect that TCP would do the rest. > > 2) MSRP mandates TLS (which is good) but this draft breaks TLS name > based authentication (and suggests implementing other specifications, > some of them still drafts, as alternative). > > 3) The mechanism proposed in this draft is already adopted by OMA in > their specifications for SIP/MSRP over mobile networks. > > > > About point 1) > > Let's suppose I want to build a SIP client implementing MSRP (with > support for MSRP protocol and MSRP relays). It should be enough as > MSRP relays are supposed to fix NAT issues. But now big vendors arrive > and decide that they want to control/monitor/manage all the MSRP > sessions. Also they don't want to build MSRP relays (as the clients > could avoid them), neither full B2BUA (which are complex/expensive), > but just want to force such MSRP inspection at IP/TCP level, so voila: > they impose routers with ALG. > > So now, if I want my SIP UA to interoperate with those ALG devices, I > need to implement this draft. Yes, the draft says something about > these ALG devices becoming a B2BUA in case they connect with a client > not supporting this specification, but let's be honest: do we really > expect a MSRP ALG device will become a SIP/MSRP full B2BUA just for > these cases? It's easier to force the clients to buy "certificated" > SIP/MSRP clients. > > > About point 2) > > A problem in most of the SIP related specifications is the abuse of > MAY and COULD words, so finally each implementor gets his own > interpretation. MSRP RFC, however, mandates (SHOULD) the usage of TLS > (TCP is for debugging purposes). This is good, very good. But now this > draft makes it difficult, just to satisfy vendors of intermediary MSRP > entities. Is it a good standardization decision? > > > > > In conclusion (just my conclusion): > > > Advantages of this draft > ---------------------------------- > > - For big vendors: > - ALG routers are cheaper than full MSRP relays or full B2BUA (for > SIP and MSRP). > - They can control/monitor/inspect users's MSRP traffic (as it's > done at IP/TCP level) > and UA's cannot avoid them. > > - For SIP&MSRP UA's developers: > - No advantages. > > - For final users: > - No advantages. > > > Disadvantages of this draft > --------------------------------------- > > - For big vendors: > - No disadvantage. > > - For SIP&MSRP UA's developers: > - Must implement this draft to interoperate with vendors implementing it= . > - Broken TLS name authentication (or invest long time and resources > implementing > supposed alternatives). > > - For final users: > - Must buy/get a UA supporting this specification. > > > Honestly I cannot understand how this draft exists. SIP and MSRP work > on top of the transport layer so if a vendor wants to play with my > MSRP traffic it should at least work at SIP/MSRP level (this is: build > a full SIP/MSRP B2BUA and don't bother the rest of SIP/MSRP devices > and implementors). > > Just my opinion. Best regards. > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From christer.holmberg@ericsson.com Wed May 25 00:29:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA2BE06D1 for ; Wed, 25 May 2011 00:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NAbucISMvFdc for ; Wed, 25 May 2011 00:29:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEBFE069A for ; Wed, 25 May 2011 00:29:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8b-4ddcafcfb721 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 65.7A.09774.FCFACDD4; Wed, 25 May 2011 09:29:19 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 09:29:18 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Simple WG Date: Wed, 25 May 2011 09:29:18 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwaS4eG7zj0IbtSSQGoSt7nYmdFgAAXy5U6 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CE@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 07:29:21 -0000 Hi, >Hi, I'm trying to understand motivation and rationale for this draft. >Please let me know if the following points (those I've understood by >reading the text) are correct: > >1) This draft is just useful for vendors manufacturing MSRP entities >behaving as ALG devices (even if the concept of "ALG" is vaguely >defined for SIP) instead of behaving as full B2BUA. These devices >(probably IP routers) just want to change/replace some line in the SDP >and expect that TCP would do the rest. Correct. In addition, for NAT traversal purpose, people want to re-use infrastructur= e used also for other types of media, rather than having to deploy MSRP rel= ays. >2) MSRP mandates TLS (which is good) but this draft breaks TLS name >based authentication (and suggests implementing other specifications, >some of them still drafts, as alternative). > >3) The mechanism proposed in this draft is already adopted by OMA in >their specifications for SIP/MSRP over mobile networks. It is also adopted by 3GPP, and I know that people want to use it also in n= on-IMS/OMA networks. >About point 1) > >Let's suppose I want to build a SIP client implementing MSRP (with >support for MSRP protocol and MSRP relays). It should be enough as >MSRP relays are supposed to fix NAT issues. But now big vendors arrive >and decide that they want to control/monitor/manage all the MSRP >sessions. Also they don't want to build MSRP relays (as the clients >could avoid them), neither full B2BUA (which are complex/expensive), >but just want to force such MSRP inspection at IP/TCP level, so voila: >they impose routers with ALG. > >So now, if I want my SIP UA to interoperate with those ALG devices, I >need to implement this draft. Yes, the draft says something about >these ALG devices becoming a B2BUA in case they connect with a client >not supporting this specification, but let's be honest: do we really >expect a MSRP ALG device will become a SIP/MSRP full B2BUA just for >these cases? It's easier to force the clients to buy "certificated" >SIP/MSRP clients. I don't know what customers you have, if you can "easily force" them to buy= things... But, at the end of the day, no matter what functionality we talk about, cus= tomers put requirements on what is going to be implemented. And, as I also indicated to Cullen, at least one vendor is planning to impl= ement a "fallback mechanism", in order to support interoperability. Regards, Christer= From R.Jesske@telekom.de Wed May 25 01:31:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9BEE06CE for ; Wed, 25 May 2011 01:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNEHmZQYT1KY for ; Wed, 25 May 2011 01:31:55 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id AB64DE06B6 for ; Wed, 25 May 2011 01:31:54 -0700 (PDT) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 25 May 2011 10:31:48 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.39]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 25 May 2011 10:31:48 +0200 From: To: , Date: Wed, 25 May 2011 10:31:47 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 Thread-Index: Acwati+0yJJ1DFSxR7qFo9RoeTw17A== Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: multipart/alternative; boundary="_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6HE111648emea1_" MIME-Version: 1.0 Subject: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:31:56 -0000 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6HE111648emea1_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have only minor comments and I think the document is ready to proceed. here are my comments: General In a couple of sections the RFC is mentions but the reference is not mentio= ned line in Section 1 4th Paragraph RFC 4976 the [RFC 4976] is missing. also in Sections 4.2, 4.3, 6.3, 7, 7.1 Section 1: IBCF correct is Interconnection Border Control Function as defined within 3= GPP TS 23.002 Therefore replace Interconnect by Interconnection Section 2 3rd Paragraph first mentioning of full name of TLS (Transaction Layer Secur= ity) missing. 4th Paragraph same for URI Section 4.3 2nd & 3rd Paragraph typo change intial INVITE to initial INVITE last paragraph 2d last line typo change therfore to therefore Section 5.1 first line typo change behavior. to behaviour. Section 5.4 3rd line typo change therefor to therefore Section 5.5 2nd paragraph last two lines typo change The ALG will see encry= pted MSRP media pacakges, but is unable to inspect the cleartext content. to The ALG will see encrypted M= SRP media packages, but is unable to inspect the clear text content. 3rd paragraph typo change cleartext to clear text Section 6.2 typo: unproteted --> unprotected eventhough --> even though allign --> align Section 6.3 typo: authenctication 1) Use a TLS authenctication mechanism defined in RFC 4975, which will succeed if there are no ALGs in the MSRP path; or change to 1) Use a TLS authentication mechanism defined in RFC 4975, which will succeed if there are no ALGs in the MSRP path; or Same in last paragraph. autentication --> authentication Section 7.1 Format problem of last paragraph + typo reciving --> receiving Mit freundlichen Gr=FC=DFen; With Best Regards Roland Jesske Achtung neue Kontaktdaten ab dem 23.05.2011 Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 58-12766 (Tel.) +49 391 580133831 (FAX) +49 171 8618-445 (Mobil) http://www.telekom.com Erleben, was verbindet. Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6HE111648emea1_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I  have only minor comments and I think the document is ready to= proceed.
 
here are my comments:
General
In a couple of sections the RFC is mentions but the reference is not m= entioned line in Section 1 4th Paragraph RFC 4976 the [RFC 4976] is missing= .
also in Sections 4.2, 4.3, 6.3, 7, 7.1
 
Section 1:
 
IBCF correct is Interconnection Border Control Function as defined wit= hin 3GPP TS 23.002
Therefore replace Int= erconnect by Interconnection
 
Section 2
 
3rd Paragraph first mentioning of full name of TLS (Transaction Layer = Security) missing.
4th Paragraph same for URI
 
Section 4.3
2nd & 3rd  Paragraph typo change intial INVITE to initial INV= ITE
last paragraph 2d last line typo change therfore to therefore
 
Section 5.1 first line typo change behavior. to behaviour.
 
Section 5.4 3rd line typo change  therefor to therefore
 
Section 5.5 2nd paragraph last two lines typo change The ALG will see encrypted MSRP media pacakges, but is=
   unable t= o inspect the cleartext content. to The ALG will see encrypted MSRP media packages, but is
   unable to inspect the clear text content.
 
3rd paragraph typo change cleartext to clear text
 
 
Section 6.2 typo:
unproteted --> unp= rotected
eventhough --> eve= n though
allign --> align <= /font>
 
Section 6.3 typo: authenctication=
 
   1) Use a TLS authen= ctication mechanism defined in RFC 4975, which
   will succeed if the= re are no ALGs in the MSRP path; or
change to
 
   1) Use a TLS authentication mechanism = defined in RFC 4975, which
   will succeed if the= re are no ALGs in the MSRP path; or
 
Same  in last paragraph.
autentication --> = authentication
 
 
Section 7.1
Format problem of las= t paragraph + typo reciving --> receiving
 
 
 

Mit freundlichen Gr=FC=DFen; Wi= th Best Regards
Roland Jesske

Ach= tung neue Kontaktdaten ab dem 23.05.2011
De= utsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+4= 9 391 580133831 (FAX)
+4= 9 171 8618-445 (Mobil)
http://www.telekom.com

Erlebe= n, was verbindet.

Deutsc= he Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
 
 
 --_000_580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6HE111648emea1_-- From saul@ag-projects.com Wed May 25 01:43:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080BCE06E2 for ; Wed, 25 May 2011 01:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yucFtNWHQLP for ; Wed, 25 May 2011 01:43:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE19E0664 for ; Wed, 25 May 2011 01:43:38 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9F529B01C3; Wed, 25 May 2011 10:43:36 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 8DCC6B017D; Wed, 25 May 2011 10:43:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 10:43:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> References: , <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:43:39 -0000 Hi, On May 25, 2011, at 9:04 AM, Christer Holmberg wrote: > Cullen, >=20 > I am deeply sorry for having to interupt your laughing, but if you = could take a few moments to read the following. >=20 > First, the text is very much based on the discussions we had in Prague = - discussions that you yourself were part of, and which outcome and way = forward I had the impresstion that your were ok with. If you don't think = the text reflects those discussions, I would be very happy with text = proposals on how to correct that. >=20 > Second, I can inform you that there is at least one (that I am aware = of) vendor that plans to implement a "fallback mechanism", for = interoperability purpose. >=20 Unless everyone does that there no certainty that endpoints doing MSRP = today will continue to interoperate. Moreover, we are doing MSRP = *today*: relay support, ACM (started the implementation when in draft = state, and updated it when RFC was published) and even this sessmatch = (draft 10 implemented), we don't plan to support anything, we already = do. We implemented all standards available, yet unless we support this = draft there could be serious interoperability issues, something doesn't = feel right. And those are my two cents. Regards, Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed May 25 02:08:32 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD44E07B7 for ; Wed, 25 May 2011 02:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRHIdS3Jv1D6 for ; Wed, 25 May 2011 02:08:31 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23F37E06F2 for ; Wed, 25 May 2011 02:08:31 -0700 (PDT) Received: by qyk29 with SMTP id 29so2385506qyk.10 for ; Wed, 25 May 2011 02:08:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr3555826qcb.247.1306314510507; Wed, 25 May 2011 02:08:30 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 02:08:30 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CE@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 11:08:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:08:32 -0000 2011/5/25 Christer Holmberg : >>1) This draft is just useful for vendors manufacturing MSRP entities >>behaving as ALG devices (even if the concept of "ALG" is vaguely >>defined for SIP) instead of behaving as full B2BUA. These devices >>(probably IP routers) just want to change/replace some line in the SDP >>and expect that TCP would do the rest. > > Correct. > > In addition, for NAT traversal purpose, people want to re-use infrastruct= ure used also for other types of media, rather than having to deploy MSRP r= elays. Ok. Perhaps authors of MSRP could take those so important "real-life" requeriments into account *before* designing MSRP protocol (RFC 4975 and 4976)? Basically current draft destroys compatibility with clients/servers implementing MSRP and MSRP relays, so we have two islands that cannot talk one to each other. The draft talks about "MSRP" but IMHO it should become a new protocol. > at least one vendor is planning to implement a "fallback mechanism", in o= rder to support interoperability. Most of the today's SIP ALG routers break, in some way, the SIP signalling: http://www.voip-info.org/wiki/view/Routers+SIP+ALG I mean 99.99% of SIP ALG routers I've tested (even most expensives). And do you expect me to believe that a SIP+MSRP ALG/SBC which magically becomes a full B2BUA ("fallback mechanism") will work ok? Sorry but I can't, too much bad experiences with SIP ALG routers ;) SIP and MSRP works on top of the transport layer. Writting a specification for application level inspection within IP/TCP routers makes no sense IMHO. BTW: Why does not this draft state that a MSRP relay should also understand "sessmatch"? are there other issues that prevent a MSRP relay to communicate with a ALG/SBC implementing this draft? (I already know about the TLS name based authentication limitation/problem). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 02:15:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9631E07B7 for ; Wed, 25 May 2011 02:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbj9b3aTpJDF for ; Wed, 25 May 2011 02:15:34 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCCAE06F8 for ; Wed, 25 May 2011 02:15:34 -0700 (PDT) Received: by qwc23 with SMTP id 23so6027429qwc.31 for ; Wed, 25 May 2011 02:15:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr3575247qcb.171.1306314933692; Wed, 25 May 2011 02:15:33 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 02:15:33 -0700 (PDT) In-Reply-To: <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> Date: Wed, 25 May 2011 11:15:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:15:35 -0000 2011/5/25 Sa=C3=BAl Ibarra Corretg=C3=A9 : > yet unless we support this draft there could be serious interoperability = issues, something doesn't feel right. Vendors of ALG/SBC will be happy. It seems important enough to break a protocol. Sad. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 02:22:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958D7E07B7 for ; Wed, 25 May 2011 02:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EUsib8R8oF2 for ; Wed, 25 May 2011 02:22:04 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D5ECEE0785 for ; Wed, 25 May 2011 02:22:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c3-4ddcca3afcfe Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.60.09774.A3ACCDD4; Wed, 25 May 2011 11:22:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 11:22:02 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 11:22:01 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwat9c8r2LrJGYEQ9682ZLU1erIBwAAba7g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> References: , <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se>, <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> In-Reply-To: <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:22:04 -0000 Hi, >>I am deeply sorry for having to interupt your laughing, but if you could = take a few moments to read the following. >> >>First, the text is very much based on the discussions we had in Prague - = discussions that you yourself were part of, and which outcome and way forwa= rd I had the impresstion that your were ok with. If=20 >>you don't think the text reflects those discussions, I would be very happ= y with text proposals on how to correct that. >> >>Second, I can inform you that there is at least one (that I am aware of) = vendor that plans to implement a "fallback mechanism", for interoperability= purpose. > >Unless everyone does that there no certainty that endpoints doing MSRP tod= ay will continue to interoperate. What will be implemented is, as for ANY technology, eventually based on cus= tomer requirements, and what type of entities they need to serve. Regards, Christer= From christer.holmberg@ericsson.com Wed May 25 02:31:26 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4843E06FC for ; Wed, 25 May 2011 02:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yENK0EwDKG3b for ; Wed, 25 May 2011 02:31:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A1C7CE06DF for ; Wed, 25 May 2011 02:31:25 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-e9-4ddccc6b14ff Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DE.53.09774.B6CCCDD4; Wed, 25 May 2011 11:31:24 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 11:31:23 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 11:31:23 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwau1F/VXWdiYq/QK2akM6mtszCogAAhGsZ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D1@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CE@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:31:26 -0000 Hi, >>>1) This draft is just useful for vendors manufacturing MSRP entities >>>behaving as ALG devices (even if the concept of "ALG" is vaguely >>>defined for SIP) instead of behaving as full B2BUA. These devices >>>(probably IP routers) just want to change/replace some line in the SDP >>>and expect that TCP would do the rest. >> >> Correct. >> >> In addition, for NAT traversal purpose, people want to re-use infrastruc= ture used also for other types of media, rather than having to deploy MSRP = relays. > >Ok. Perhaps authors of MSRP could take those so important "real-life" >requeriments into account *before* designing MSRP protocol (RFC 4975 >and 4976)? As Cher would put it: If I could turn back time... >Basically current draft destroys compatibility with clients/servers >implementing MSRP and MSRP relays, so we have two islands that cannot >talk one to each other. The draft talks about "MSRP" but IMHO it >should become a new protocol. >>at least one vendor is planning to implement a "fallback mechanism", in o= rder to support interoperability. > >Most of the today's SIP ALG routers break, in some way, the SIP signalling= : >http://www.voip-info.org/wiki/view/Routers+SIP+ALG > >I mean 99.99% of SIP ALG routers I've tested (even most expensives). >And do you expect me to believe that a SIP+MSRP ALG/SBC which >magically becomes a full B2BUA ("fallback mechanism") will work ok? >Sorry but I can't, too much bad experiences with SIP ALG routers ;) I expect that SIP ALGs will do whatever customers require them to do... ...and if they don't, the customers will most likely go somewhere else. Regards, Christer= From saul@ag-projects.com Wed May 25 02:44:11 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F139CE07DE for ; Wed, 25 May 2011 02:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2uUmxjCaw6bP for ; Wed, 25 May 2011 02:44:11 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5BD99E07D9 for ; Wed, 25 May 2011 02:44:11 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 941B7B01B3; Wed, 25 May 2011 11:44:10 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id F2E9FB00E6; Wed, 25 May 2011 11:44:09 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 11:44:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se>, <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:44:12 -0000 On May 25, 2011, at 11:22 AM, Christer Holmberg wrote: > Hi, >=20 >>> I am deeply sorry for having to interupt your laughing, but if you = could take a few moments to read the following. >>>=20 >>> First, the text is very much based on the discussions we had in = Prague - discussions that you yourself were part of, and which outcome = and way forward I had the impresstion that your were ok with. If=20 >>> you don't think the text reflects those discussions, I would be very = happy with text proposals on how to correct that. >>>=20 >>> Second, I can inform you that there is at least one (that I am aware = of) vendor that plans to implement a "fallback mechanism", for = interoperability purpose. >>=20 >> Unless everyone does that there no certainty that endpoints doing = MSRP today will continue to interoperate. >=20 > What will be implemented is, as for ANY technology, eventually based = on customer requirements, and what type of entities they need to serve. >=20 So, we can potentially break interoperability because vendor X wants a = simple approach (sessmatch) instead of implementing a proper MSRP B2BUA. = Personally I would only agree on going further with sessmatch if the = fallback mechanism was specified as a MUST. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 02:44:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858CE07E8 for ; Wed, 25 May 2011 02:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjFpZD3ty4eF for ; Wed, 25 May 2011 02:44:20 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A33CCE07E7 for ; Wed, 25 May 2011 02:44:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b6-4ddccf72908a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F3.D7.09774.27FCCDD4; Wed, 25 May 2011 11:44:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 11:44:18 +0200 From: Christer Holmberg To: "'R.Jesske@telekom.de'" , "simple@ietf.org" Date: Wed, 25 May 2011 11:44:17 +0200 Thread-Topic: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Roland's comments Thread-Index: Acwati+0yJJ1DFSxR7qFo9RoeTw17AACK9sg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C864@ESESSCMS0356.eemea.ericsson.se> References: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D0840FB4DB6@HE111648.emea1.cds.t-internal.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Roland's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 09:44:20 -0000 Hi Roland, =20 >I have only minor comments and I think the document is ready to proceed. > >Here are my comments: >General >In a couple of sections the RFC is mentions but the reference is not menti= oned line in Section 1 4th Paragraph RFC 4976 the [RFC 4976] is missing. >also in Sections 4.2, 4.3, 6.3, 7, 7.1 =20 The intention is to add the reference only for the first occurance where th= e RFC is mentioned.=20 -------- >Section 1: > >IBCF correct is Interconnection Border Control Function as defined within = 3GPP TS 23.002 >Therefore replace Interconnect by Interconnection Will do. -------- >Section 2=20 >=20 >3rd Paragraph first mentioning of full name of TLS (Transaction Layer Secu= rity) missing. >4th Paragraph same for URI Will do. -------- =20 >Section 4.3 >2nd & 3rd Paragraph typo change intial INVITE to initial INVITE >last paragraph 2d last line typo change therfore to therefore =20 Will do. -------- >Section 5.1 first line typo change behavior. to behaviour.=20 Will do. -------- =20 >Section 5.4 3rd line typo change therefor to therefore =20 Will do. -------- >Section 5.5 2nd paragraph last two lines typo change The ALG will see encr= ypted MSRP media pacakges, but is > unable to inspect the cleartext content. to The ALG will see encrypted = MSRP media packages, but is > unable to inspect the clear text content.=20 > >3rd paragraph typo change cleartext to clear text Will do. -------- =20 >Section 6.2 typo: >unproteted --> unprotected >eventhough --> even though >allign --> align=20 =20 Will do. -------- >Section 6.3 typo: authenctication >=20 > 1) Use a TLS authenctication mechanism defined in RFC 4975 , which > will succeed if there are no ALGs in the MSRP path; or change to=20 >=20 > 1) Use a TLS authentication mechanism defined in RFC 4975 , which > will succeed if there are no ALGs in the MSRP path; or > >Same in last paragraph. >autentication --> authentication Will do. -------- =20 =20 >Section 7.1=20 >Format problem of last paragraph + typo reciving --> receiving=20 Will do. -------- =20 =20 Thank You very much for Your comments! Regards, Christer= From christer.holmberg@ericsson.com Wed May 25 03:02:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD50E07BC for ; Wed, 25 May 2011 03:02:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DN1iCTBUeRy for ; Wed, 25 May 2011 03:02:22 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2A362E07CF for ; Wed, 25 May 2011 03:02:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-99-4ddcd3ad07e7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.89.20773.DA3DCDD4; Wed, 25 May 2011 12:02:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 12:02:20 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Wed, 25 May 2011 12:02:20 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwawE1fJnPwUJGNSwu/wDXtsKoAlgAAiTEg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> References: , <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se>, <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:02:23 -0000 Hi,=20 >>>>I am deeply sorry for having to interupt your laughing, but if you coul= d take a few moments to read the following. >>>>=20 >>>>First, the text is very much based on the discussions we had in=20 >>>>Prague - discussions that you yourself were part of, and which outcome = and way forward I had the impresstion that your were ok with. If you don't= =20 >>>>think the text reflects those discussions, I would be very happy with t= ext proposals on how to correct that. >>>>=20 >>>>Second, I can inform you that there is at least one (that I am aware of= ) vendor that plans to implement a "fallback mechanism", for interoperabili= ty=20 >>>>purpose. >>>=20 >>>Unless everyone does that there no certainty that endpoints doing MSRP t= oday will continue to interoperate. >>=20 >>What will be implemented is, as for ANY technology, eventually based on c= ustomer requirements, and what type of entities they need to serve. >=20 >So, we can potentially break interoperability because vendor X wants a sim= ple approach (sessmatch) instead of implementing a proper MSRP B2BUA.=20 Because customer X wants a simple approach in order to deploy standard MSRP= in the first place. >Personally I would only agree on going further with sessmatch if the fallb= ack mechanism was specified as a MUST. Ok. Regards, Christer From ibc@aliax.net Wed May 25 03:24:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1D1E06D0 for ; Wed, 25 May 2011 03:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pD7bVaL4Hx4P for ; Wed, 25 May 2011 03:24:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8E03FE0697 for ; Wed, 25 May 2011 03:24:48 -0700 (PDT) Received: by qyk7 with SMTP id 7so5136205qyk.10 for ; Wed, 25 May 2011 03:24:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2821074qcb.285.1306319088014; Wed, 25 May 2011 03:24:48 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 03:24:47 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 12:24:47 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:24:49 -0000 2011/5/25 Christer Holmberg : > Because customer X wants a simple approach in order to deploy standard MS= RP in the first place. Standard MSRP? Let's say MSRP is defined in 3 documents A, B and C (being C this draft). C breaks A and B. Which kind of standard is it? Maybe C is the only "standard" customer/vendor X cares about? --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 03:38:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EE0E0703 for ; Wed, 25 May 2011 03:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag9g9t5GP6ST for ; Wed, 25 May 2011 03:38:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 696F5E0693 for ; Wed, 25 May 2011 03:38:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f0-4ddcdc0a9200 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 17.24.20773.A0CDCDD4; Wed, 25 May 2011 12:38:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 12:38:02 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 12:38:01 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwaxfpWPUUO16tJQH2RdaCB1pkdXQAAbkjg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:38:04 -0000 What I meant with "standard" is something that's been published as an RFC b= y IETF.=20 -----Original Message----- From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: 25. toukokuuta 2011 13:25 To: Christer Holmberg Cc: Sa=FAl Ibarra Corretg=E9; Cullen Jennings; Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch 2011/5/25 Christer Holmberg : > Because customer X wants a simple approach in order to deploy standard MS= RP in the first place. Standard MSRP? Let's say MSRP is defined in 3 documents A, B and C (being C this draft). C= breaks A and B. Which kind of standard is it? Maybe C is the only "standar= d" customer/vendor X cares about? -- I=F1aki Baz Castillo From ag@ag-projects.com Wed May 25 03:42:16 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B52E0704 for ; Wed, 25 May 2011 03:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEUHXgXTBKNW for ; Wed, 25 May 2011 03:42:15 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 46682E0675 for ; Wed, 25 May 2011 03:42:15 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8D837B01BF; Wed, 25 May 2011 12:42:14 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 8250AB0192; Wed, 25 May 2011 12:42:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 12:42:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:42:16 -0000 Hello Christer, In very simple words, your draft simply breaks apart everything MSRP as = defined per in RFC 4975 and RFC 4976 stand for. =20 You created a complete new protocol with its own behavior that does not = interoperate with anything else and you call it MSRP. This is unacceptable! Adrian On May 25, 2011, at 12:38 PM, Christer Holmberg wrote: >=20 > What I meant with "standard" is something that's been published as an = RFC by IETF.=20 >=20 > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net]=20 > Sent: 25. toukokuuta 2011 13:25 > To: Christer Holmberg > Cc: Sa=FAl Ibarra Corretg=E9; Cullen Jennings; Simple WG > Subject: Re: [Simple] About draft-ietf-simple-sessmatch >=20 > 2011/5/25 Christer Holmberg : >> Because customer X wants a simple approach in order to deploy = standard MSRP in the first place. >=20 > Standard MSRP? >=20 > Let's say MSRP is defined in 3 documents A, B and C (being C this = draft). C breaks A and B. Which kind of standard is it? Maybe C is the = only "standard" customer/vendor X cares about? >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ibc@aliax.net Wed May 25 03:42:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2555A13001A for ; Wed, 25 May 2011 03:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIAmOnpx7qvB for ; Wed, 25 May 2011 03:42:20 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 83B78130019 for ; Wed, 25 May 2011 03:42:20 -0700 (PDT) Received: by qyk7 with SMTP id 7so5145072qyk.10 for ; Wed, 25 May 2011 03:42:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr3613981qci.209.1306320139792; Wed, 25 May 2011 03:42:19 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 03:42:19 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 12:42:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:42:21 -0000 2011/5/25 Christer Holmberg : > What I meant with "standard" is something that's been published as an RFC= by IETF. ...regardless of how many other standards it breaks or corrupts. --=20 I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Wed May 25 03:56:30 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A478BE06F0 for ; Wed, 25 May 2011 03:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wma8L+aUdXvs for ; Wed, 25 May 2011 03:56:29 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 056B6E0681 for ; Wed, 25 May 2011 03:56:28 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p4PAtJqY024546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 25 May 2011 12:56:20 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 25 May 2011 12:56:17 +0200 From: "DRAGE, Keith (Keith)" To: Adrian Georgescu , Christer Holmberg Date: Wed, 25 May 2011 12:56:17 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwayHimbhhtSOpeQWGTLGY0vKbClQAAYvDA Message-ID: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> In-Reply-To: <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 10:56:30 -0000 The problem with comments like this, and this is repeating a past comment i= n the same vein, is that it completely fails to back up the statement with = specifics. Previous arguments seem to have centred round your previous implementation = no longer words so the specification must be technical incorrect, but again= have not been backed up with specifics, or even any precise statements abo= ut which version of the RFC you have actually implemented. Please make specific technical arguments so we can make our own decision. W= hich bits of the protocol break and why? Regards Keith > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf > Of Adrian Georgescu > Sent: 25 May 2011 11:42 > To: Christer Holmberg > Cc: Cullen Jennings; Simple WG > Subject: Re: [Simple] About draft-ietf-simple-sessmatch >=20 > Hello Christer, >=20 > In very simple words, your draft simply breaks apart everything MSRP as > defined per in RFC 4975 and RFC 4976 stand for. >=20 > You created a complete new protocol with its own behavior that does not > interoperate with anything else and you call it MSRP. >=20 > This is unacceptable! >=20 > Adrian >=20 > On May 25, 2011, at 12:38 PM, Christer Holmberg wrote: >=20 > > > > What I meant with "standard" is something that's been published as an > RFC by IETF. > > > > -----Original Message----- > > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > > Sent: 25. toukokuuta 2011 13:25 > > To: Christer Holmberg > > Cc: Sa=FAl Ibarra Corretg=E9; Cullen Jennings; Simple WG > > Subject: Re: [Simple] About draft-ietf-simple-sessmatch > > > > 2011/5/25 Christer Holmberg : > >> Because customer X wants a simple approach in order to deploy standard > MSRP in the first place. > > > > Standard MSRP? > > > > Let's say MSRP is defined in 3 documents A, B and C (being C this > draft). C breaks A and B. Which kind of standard is it? Maybe C is the > only "standard" customer/vendor X cares about? > > > > -- > > I=F1aki Baz Castillo > > > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple > > >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From gonzalo.camarillo@ericsson.com Wed May 25 04:02:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37009E0681 for ; Wed, 25 May 2011 04:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v260adusIYHF for ; Wed, 25 May 2011 04:02:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBA9E0690 for ; Wed, 25 May 2011 04:02:56 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-53-4ddce1df71bc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6A.90.09774.FD1ECDD4; Wed, 25 May 2011 13:02:55 +0200 (CEST) Received: from [131.160.37.44] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Wed, 25 May 2011 13:02:55 +0200 Message-ID: <4DDCE1DF.2050901@ericsson.com> Date: Wed, 25 May 2011 14:02:55 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Ben Campbell References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:02:57 -0000 Hi, given that the backwards compatibility properties of this extension have caused some concern, the draft needs to do a better job describing them. Being explicit about them is important. The last paragraph of Section 1 should be edited so that it captures the different scenarios that have been discussed on this list. The authors may even consider having a brief section about backwards compatibility, which would also include the comments about having to implement regular MRSP procedures as the fall-back mechanism at a MUST or a SHOULD level (whatever the WG decides). Also, within that paragraph, the following sentence is confusing: > MSRP entities that do not implement the sessmatch extension, and > communicate with ALGs that do not implement MSRP B2BUA functionality, > can normally not establish MSRP sessions, since the session matching > will fail in case the address information of the SDP a=path attribute > has been modified by the ALGs. That is not a standard scenario because before this extension was defined, ALGs needed to implement MSRP B2BUA functionality. The draft can say that this extension enables that scenario, but the draft should not talk about non-standard behavior in the context of backwards compatibility because things can get quite confusing. Thanks, Gonzalo On 23/05/2011 6:51 PM, Ben Campbell wrote: > This is a Working Group Last Call of draft-ietf-simple-msrp-sessmatch-11: > > http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11 > > Please note that this draft contains substantial new text since version 10, primarily concerning the use of an option tag. Even if you were happy with version 10, please review this version. > > The WGLC will conclude on 6 June 2011. Please send your comments, including nits and "this is ready to go" type comments, to the authors and the working group list. > > Thanks! > > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > From saul@ag-projects.com Wed May 25 04:06:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643E7E06F8 for ; Wed, 25 May 2011 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPSe6dhDpIqA for ; Wed, 25 May 2011 04:06:25 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BF20DE0681 for ; Wed, 25 May 2011 04:06:24 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2ADDBB01B4; Wed, 25 May 2011 13:06:24 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 7B8A9B0192; Wed, 25 May 2011 13:06:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 25 May 2011 13:06:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:06:25 -0000 On May 25, 2011, at 12:56 PM, DRAGE, Keith (Keith) wrote: > The problem with comments like this, and this is repeating a past = comment in the same vein, is that it completely fails to back up the = statement with specifics. >=20 > Previous arguments seem to have centred round your previous = implementation no longer words so the specification must be technical = incorrect, but again have not been backed up with specifics, or even any = precise statements about which version of the RFC you have actually = implemented. >=20 > Please make specific technical arguments so we can make our own = decision. Which bits of the protocol break and why? >=20 Take the following case: Alice does not support sessmatch but Bob does, = and Bob is using a MSRP-sessmatch-enabled ALG/SBC. Whith the current = state of the draft, they will not be able to talk to each other unless = the ALG falls back to B2BUA mode. This fallback, however is not mandated = by the sessmatch draft. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed May 25 04:07:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7F7E0707 for ; Wed, 25 May 2011 04:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6+26zFmqPLv for ; Wed, 25 May 2011 04:07:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E92BE0704 for ; Wed, 25 May 2011 04:07:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so6092058qwc.31 for ; Wed, 25 May 2011 04:07:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr3640729qcb.171.1306321625595; Wed, 25 May 2011 04:07:05 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 04:07:05 -0700 (PDT) In-Reply-To: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> Date: Wed, 25 May 2011 13:07:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:07:07 -0000 2011/5/25 DRAGE, Keith (Keith) : > Previous arguments seem to have centred round your previous implementatio= n no longer words so the specification must be technical incorrect, but aga= in have not been backed up with specifics, or even any precise statements a= bout which version of the RFC you have actually implemented. > > Please make specific technical arguments so we can make our own decision.= Which bits of the protocol break and why? I think it's very clear. This draft introduces: - Incompatibility with MSRP endpoints not implementing this draft (please don't assume that all the vendors will implement a magic/exotic "fallback mechanism" as it will not occur) =3D> bit reaks RFC 4975. - Incompatibility with MSRP relays =3D> it breaks RFC 4976. - TLS name based authentication broken =3D> it breaks RFC's 4975 and 4976 (= again). So this draft is in detrimental of existing full implementations of MSRP protocol, and its purpose is just to satisfy vendors of AGL boxes. IMHO it's *very* clear that this draft breaks things. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 04:17:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10AFE0690 for ; Wed, 25 May 2011 04:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+XVzxmifT8K for ; Wed, 25 May 2011 04:17:55 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CDCBAE0681 for ; Wed, 25 May 2011 04:17:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 276BDB01B6; Wed, 25 May 2011 13:17:54 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id B18FCB0192; Wed, 25 May 2011 13:17:52 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: Date: Wed, 25 May 2011 13:17:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:17:55 -0000 Dear Keith, By saying this you take the innocent approach that this draft is correct = and the rest of us concerned has to prove otherwise. The concerns about = this draft have been iterated countless of times and are ignored = systematically or responded to by further filling up the document with a = convoluted workaround logic that departs so much from the reality. By implementing this draft an implementation will signal and use: - Different SDP media description - Different connection model - Original security properties compromised This is a different protocol all together, it MUST not be called MSRP = just because it uses chunks and some similar headers in some of its = payloads.=20 How about taking a different approach? The exiting MSRP implementations = are working just fine and the MSRP standards are right, this is = confirmed by live deployments. This draft MUST prove that it interoperates with the existing MSRP = standards and MSRP implementations in place. Not the other way around. = Otherwise call it something else that does not contain the MSRP in the = name. =20 Which approach is more reasonable for you? Adrian On May 25, 2011, at 12:56 PM, DRAGE, Keith (Keith) wrote: > The problem with comments like this, and this is repeating a past = comment in the same vein, is that it completely fails to back up the = statement with specifics. >=20 > Previous arguments seem to have centred round your previous = implementation no longer words so the specification must be technical = incorrect, but again have not been backed up with specifics, or even any = precise statements about which version of the RFC you have actually = implemented. >=20 > Please make specific technical arguments so we can make our own = decision. Which bits of the protocol break and why? >=20 > Regards >=20 > Keith >=20 >> -----Original Message----- >> From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf >> Of Adrian Georgescu >> Sent: 25 May 2011 11:42 >> To: Christer Holmberg >> Cc: Cullen Jennings; Simple WG >> Subject: Re: [Simple] About draft-ietf-simple-sessmatch >>=20 >> Hello Christer, >>=20 >> In very simple words, your draft simply breaks apart everything MSRP = as >> defined per in RFC 4975 and RFC 4976 stand for. >>=20 >> You created a complete new protocol with its own behavior that does = not >> interoperate with anything else and you call it MSRP. >>=20 >> This is unacceptable! >>=20 >> Adrian >>=20 >> On May 25, 2011, at 12:38 PM, Christer Holmberg wrote: >>=20 >>>=20 >>> What I meant with "standard" is something that's been published as = an >> RFC by IETF. >>>=20 >>> -----Original Message----- >>> From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >>> Sent: 25. toukokuuta 2011 13:25 >>> To: Christer Holmberg >>> Cc: Sa=FAl Ibarra Corretg=E9; Cullen Jennings; Simple WG >>> Subject: Re: [Simple] About draft-ietf-simple-sessmatch >>>=20 >>> 2011/5/25 Christer Holmberg : >>>> Because customer X wants a simple approach in order to deploy = standard >> MSRP in the first place. >>>=20 >>> Standard MSRP? >>>=20 >>> Let's say MSRP is defined in 3 documents A, B and C (being C this >> draft). C breaks A and B. Which kind of standard is it? Maybe C is = the >> only "standard" customer/vendor X cares about? >>>=20 >>> -- >>> I=F1aki Baz Castillo >>> >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Wed May 25 04:26:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F75E0690 for ; Wed, 25 May 2011 04:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8RJlSNlulen for ; Wed, 25 May 2011 04:26:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 79035E0694 for ; Wed, 25 May 2011 04:26:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ef-4ddce75ce8e7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.08.09774.C57ECDD4; Wed, 25 May 2011 13:26:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 13:26:20 +0200 From: Christer Holmberg To: 'Adrian Georgescu' , "DRAGE, Keith (Keith)" Date: Wed, 25 May 2011 13:26:19 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: AcwazWU38sJJ6JdyQCSVBlWnVsp5DQAAE95Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> In-Reply-To: <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.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-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:26:22 -0000 Hi,=20 >By implementing this draft an implementation will signal and use: > >- Different SDP media description Please explain. >- Different connection model Please explain. The only technical (not taking the security issues into considerations) dif= ference between sessmatch and 4975 is the way it matches MSRP messages to a= session. >- Original security properties compromised > >This is a different protocol all together, it MUST not be called MSRP just= because it uses chunks and some similar headers in some of its payloads.= =20 > >How about taking a different approach? The exiting MSRP implementations ar= e working just fine and the MSRP standards are right, this is confirmed by = live=20 >deployments. In certain deployments, with certain characteristics, I am sure existing MS= RP implementations work just fine. I have never claimed, or seen anyone els= e claiming, anything else. The draft tries to explain the scenarios where sessmatch bring value. If yo= u don't think it's clear enough I am happy to add text. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 04:29:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D42E0694 for ; Wed, 25 May 2011 04:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOaMkRTRaKoY for ; Wed, 25 May 2011 04:29:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D3791E0680 for ; Wed, 25 May 2011 04:29:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d1-4ddce81037e8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 48.19.09774.018ECDD4; Wed, 25 May 2011 13:29:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 13:29:20 +0200 From: Christer Holmberg To: Gonzalo Camarillo , Ben Campbell Date: Wed, 25 May 2011 13:29:19 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 Thread-Index: Acway1D3DH1i4/eNTOOGndoXkxrFSQAAd+Gg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> In-Reply-To: <4DDCE1DF.2050901@ericsson.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-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:29:23 -0000 Hi,=20 >given that the backwards compatibility properties of this extension have c= aused some concern, the draft needs to do a better job describing them. >Being explicit about them is important. The last paragraph of Section 1 sh= ould be edited so that it captures the different scenarios that have been=20 >discussed on this list. The authors may even consider having a brief secti= on about backwards compatibility, which would also include the comments abo= ut=20 >having to implement regular MRSP procedures as the fall-back mechanism at = a MUST or a SHOULD level (whatever the WG decides). Based on Ben's WGLC comments, the current proposal is to have a fallback me= chanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger tha= n that, but there ARE networks (e.g. defined by OMA) where fallback will ne= ver be used, so for that reason I don't think we should make it a MUST.=20 But, that's just my personal opinion. At the end of the day I will of cours= e go with whatever the WG decides... >> MSRP entities that do not implement the sessmatch extension, and >> communicate with ALGs that do not implement MSRP B2BUA functionality, >> can normally not establish MSRP sessions, since the session matching >> will fail in case the address information of the SDP a=3Dpath attribute >> has been modified by the ALGs. > >That is not a standard scenario because before this extension was defined,= ALGs needed to implement MSRP B2BUA functionality. The draft can say that = this >extension enables that scenario, but the draft should not talk about = non-standard behavior in the context of backwards compatibility because thi= ngs can=20 >get quite confusing. Ok. Regards, Christer On 23/05/2011 6:51 PM, Ben Campbell wrote: > This is a Working Group Last Call of draft-ietf-simple-msrp-sessmatch-11: >=20 > http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11 >=20 > Please note that this draft contains substantial new text since version 1= 0, primarily concerning the use of an option tag. Even if you were happy wi= th version 10, please review this version. >=20 > The WGLC will conclude on 6 June 2011. Please send your comments, includi= ng nits and "this is ready to go" type comments, to the authors and the wor= king group list. >=20 > Thanks! >=20 > Ben.=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Wed May 25 04:39:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F44E0722 for ; Wed, 25 May 2011 04:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rqkE8J+4zB4 for ; Wed, 25 May 2011 04:39:57 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 335B4E071F for ; Wed, 25 May 2011 04:39:57 -0700 (PDT) Received: by qyk29 with SMTP id 29so2461204qyk.10 for ; Wed, 25 May 2011 04:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr3661026qcb.171.1306323596699; Wed, 25 May 2011 04:39:56 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 04:39:56 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 13:39:56 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:39:58 -0000 2011/5/25 Christer Holmberg : > Based on Ben's WGLC comments, the current proposal is to have a fallback = mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger t= han that, but there ARE networks (e.g. defined by OMA) where fallback will = never be used, so for that reason I don't think we should make it a MUST. Outside OMA/IMS world, there are millons of local or public (Internet) SIP networks, and usually commercial IP/TCP routers (those provided by the Internet Provider) come with builtin SIP ALG enabled by default. If these vendors also include MSRP ALG and the fallback mechanism is not a MUST, they wont implement such mechanism, so bye bye MSRP in "open" networks. Anyhow, there are dozens of specifications in OMA/RCS/IMS that take IETF RFC's and incorporate custom additions. Such a specification could take place in OMA world (stating that the "fallback mechanism" is not a MUST) so the rest of the world is not bothered. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 04:42:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4835E0722 for ; Wed, 25 May 2011 04:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8icdNic2d8Xq for ; Wed, 25 May 2011 04:42:23 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC53E0657 for ; Wed, 25 May 2011 04:42:23 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 44BD8B01BE; Wed, 25 May 2011 13:42:22 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id BAF0BB0192; Wed, 25 May 2011 13:42:21 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 13:42:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:42:23 -0000 > The draft tries to explain the scenarios where sessmatch bring value. = If you don't think it's clear enough I am happy to add text. You must use the word MUST only: MUST become a full SIP/MSRP ALG to maintain compatibility with the = original MSRP specifications. Adrian From ibc@aliax.net Wed May 25 04:48:30 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30F4E0657 for ; Wed, 25 May 2011 04:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 755eKuuo9nxe for ; Wed, 25 May 2011 04:48:30 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7CBE0618 for ; Wed, 25 May 2011 04:48:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so2465705qyk.10 for ; Wed, 25 May 2011 04:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr3666761qcb.171.1306324109539; Wed, 25 May 2011 04:48:29 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 04:48:29 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 13:48:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:48:31 -0000 2011/5/25 Christer Holmberg : > In certain deployments, with certain characteristics, I am sure existing = MSRP implementations work just fine. I have never claimed, or seen anyone e= lse claiming, anything else. By specification is clear enough that this draft breaks compatibility with MSRP entities "just" implementing RFC 4975 and 4976. Who cares "certain deployments with certain characteristics"? how can that be an argument? We are talking about a standard. > The draft tries to explain the scenarios where sessmatch bring value. If = you don't think it's clear enough I am happy to add text. Sessmatch adds no value as it would be never needed if MSRP is not handled by IP/TCP level boxes. The correct behavior would be MSRP B2BUA's so sessmatch is just a hack to allow these ALG boxes to work. sessmatch is not needed at all when handling SIP and MSRP on top of the transport layer (as it should always be). Anyhow describing the scenarios in which things work and things don't work is not enough. A specification based on XXX protocol should not break XXX protocol itself. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 04:49:22 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6096BE0657 for ; Wed, 25 May 2011 04:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipN+f6w79CCc for ; Wed, 25 May 2011 04:49:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1CEE0618 for ; Wed, 25 May 2011 04:49:21 -0700 (PDT) Received: by qwc23 with SMTP id 23so6116641qwc.31 for ; Wed, 25 May 2011 04:49:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr3655430qci.209.1306324161047; Wed, 25 May 2011 04:49:21 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 04:49:20 -0700 (PDT) In-Reply-To: <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> Date: Wed, 25 May 2011 13:49:20 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:49:22 -0000 2011/5/25 Adrian Georgescu : > MUST become a full SIP/MSRP ALG to maintain compatibility with the origin= al MSRP specifications. Hi Adrian, I think you mean "MUST become a full SIP/MSRP B2BUA" ;) --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 04:55:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EACE0735 for ; Wed, 25 May 2011 04:55:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fkdtDP7rELx for ; Wed, 25 May 2011 04:55:52 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 950E2E0713 for ; Wed, 25 May 2011 04:55:52 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D9C49B01BE; Wed, 25 May 2011 13:55:51 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 0DB95B0192; Wed, 25 May 2011 13:55:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Adrian Georgescu In-Reply-To: Date: Wed, 25 May 2011 13:55:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <356AD202-4B21-473B-B62B-2A1997B273A9@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 11:55:53 -0000 Yes you are right, my mind was cleansed by the ALG poison, so it must = read: "MUST become a full SIP/MSRP B2BUA" Adrian On May 25, 2011, at 1:49 PM, I=C3=B1aki Baz Castillo wrote: > 2011/5/25 Adrian Georgescu : >> MUST become a full SIP/MSRP ALG to maintain compatibility with the = original MSRP specifications. >=20 > Hi Adrian, I think you mean "MUST become a full SIP/MSRP B2BUA" ;) >=20 > --=20 > I=C3=B1aki Baz Castillo > >=20 From christer.holmberg@ericsson.com Wed May 25 05:08:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E18EE0657 for ; Wed, 25 May 2011 05:08:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFIq1mCL+NqA for ; Wed, 25 May 2011 05:08:38 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 622A8E0618 for ; Wed, 25 May 2011 05:08:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-80-4ddcf145a3fc Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E1.74.09774.541FCDD4; Wed, 25 May 2011 14:08:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 14:08:34 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 14:08:33 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 Thread-Index: Acwa0HmRaPYeRThkR36Ajm14b1p+9wAA7VHw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86E@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:08:39 -0000 Hi,=20 >>Based on Ben's WGLC comments, the current proposal is to have a fallback = mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger t= han=20 >>that, but there ARE networks (e.g. defined by OMA) where fallback will ne= ver be used, so for that reason I don't think we should make it a MUST. > >Outside OMA/IMS world, there are millons of local or public (Internet) SIP= networks, and usually commercial IP/TCP routers (those provided by the=20 >Internet Provider) come with builtin SIP ALG enabled by default. >If these vendors also include MSRP ALG and the fallback mechanism is not a= MUST, they wont implement such mechanism, so bye bye MSRP in "open" networ= ks. So, how do these SIP ALGs behave today when it comes to MSRP? Regards, Christer From christer.holmberg@ericsson.com Wed May 25 05:32:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724BBE0713 for ; Wed, 25 May 2011 05:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHeoTud7rwyg for ; Wed, 25 May 2011 05:32:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B56E6E0657 for ; Wed, 25 May 2011 05:32:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-37-4ddcf6c67058 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5E.B4.20773.6C6FCDD4; Wed, 25 May 2011 14:32:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 14:32:05 +0200 From: Christer Holmberg To: 'Adrian Georgescu' , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 14:32:05 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa0rKctg1lpPMwTIq3RIuFssuVogABOL3g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B273A9@ag-projects.com> In-Reply-To: <356AD202-4B21-473B-B62B-2A1997B273A9@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:32:08 -0000 Hi, How do SIP ALGs work today, when it comes to MSRP? Regards, Christer =20 -----Original Message----- From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 Sent: 25. toukokuuta 2011 14:56 To: I=F1aki Baz Castillo Cc: Christer Holmberg; Cullen Jennings; DRAGE, Keith (Keith); Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch Yes you are right, my mind was cleansed by the ALG poison, so it must read: "MUST become a full SIP/MSRP B2BUA" Adrian On May 25, 2011, at 1:49 PM, I=F1aki Baz Castillo wrote: > 2011/5/25 Adrian Georgescu : >> MUST become a full SIP/MSRP ALG to maintain compatibility with the origi= nal MSRP specifications. >=20 > Hi Adrian, I think you mean "MUST become a full SIP/MSRP B2BUA" ;) >=20 > -- > I=F1aki Baz Castillo > >=20 From ibc@aliax.net Wed May 25 05:44:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D23E072E for ; Wed, 25 May 2011 05:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgmGZbWnSEZa for ; Wed, 25 May 2011 05:44:03 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49BE0723 for ; Wed, 25 May 2011 05:44:03 -0700 (PDT) Received: by qyk29 with SMTP id 29so2496134qyk.10 for ; Wed, 25 May 2011 05:44:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.130.65 with SMTP id r1mr3651570qas.310.1306327442531; Wed, 25 May 2011 05:44:02 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 05:44:02 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86E@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 14:44:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:44:03 -0000 2011/5/25 Christer Holmberg : >>>Based on Ben's WGLC comments, the current proposal is to have a fallback= mechanism as a STRONGLY RECOMMENDED. I don't mind having it even stronger = than >>>that, but there ARE networks (e.g. defined by OMA) where fallback will n= ever be used, so for that reason I don't think we should make it a MUST. >> >>Outside OMA/IMS world, there are millons of local or public (Internet) SI= P networks, and usually commercial IP/TCP routers (those provided by the >>Internet Provider) come with builtin SIP ALG enabled by default. >>If these vendors also include MSRP ALG and the fallback mechanism is not = a MUST, they wont implement such mechanism, so bye bye MSRP in "open" netwo= rks. > > So, how do these SIP ALGs behave today when it comes to MSRP? I don't know, I just hate SIP ALG's. I would like SIP ALG's not no exist anymore as I don't want my router to inspect and modify my application layer data. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 05:52:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82874E068C for ; Wed, 25 May 2011 05:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSi5rBiyWzzw for ; Wed, 25 May 2011 05:52:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id C48ABE067C for ; Wed, 25 May 2011 05:52:48 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B95EAB01BE; Wed, 25 May 2011 14:52:47 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 96754B0192; Wed, 25 May 2011 14:52:46 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 14:52:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:52:49 -0000 Today SIP ALG breaks SIP most of the time. Actually I have never seen a = single one that works and I deployed large SIP for 8 years now. They = simply mangle SIP headers without understanding that there is a state = machine behind. This is possible and easy when SIP signaling travels in clear text over = UDP, which is today most of the time as it was allowed unfortunately by = the same people that care about sess-match today. If traffic was TLS the = ALGs would have never existed today and SIP would just work today = without the pains we have. So typically a programmer is hired for 4 hours to implement 'the SIP ALG = feature' that a competitor has. He will write 4 lines of code without = understanding the state machine of any protocol involved by doing a = regexp over clear text to replace strings in the sip packet. Then people = crowd on wikipedia to explain how to turn off the feature that breaks = SIP. Sad. If you allow MSRP over TCP, same will happen all over again. Your draft explicitly creates the possibility for breaking MSRP sessions = to pieces by intermediates. It was not possible before, now suddenly it = is. The experience shows that this will be abused simply by incompetence = if nothing else to the extend that people will perceive that MSRP = protocol does not work and is broken. Same like SIP is today. Adrian On May 25, 2011, at 2:32 PM, Christer Holmberg wrote: >=20 > Hi, >=20 > How do SIP ALGs work today, when it comes to MSRP? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > -----Original Message----- > From: Adrian Georgescu [mailto:ag@ag-projects.com]=20 > Sent: 25. toukokuuta 2011 14:56 > To: I=F1aki Baz Castillo > Cc: Christer Holmberg; Cullen Jennings; DRAGE, Keith (Keith); Simple = WG > Subject: Re: [Simple] About draft-ietf-simple-sessmatch >=20 > Yes you are right, my mind was cleansed by the ALG poison, so it must = read: >=20 >=20 > "MUST become a full SIP/MSRP B2BUA" >=20 > Adrian >=20 >=20 >=20 > On May 25, 2011, at 1:49 PM, I=F1aki Baz Castillo wrote: >=20 >> 2011/5/25 Adrian Georgescu : >>> MUST become a full SIP/MSRP ALG to maintain compatibility with the = original MSRP specifications. >>=20 >> Hi Adrian, I think you mean "MUST become a full SIP/MSRP B2BUA" ;) >>=20 >> -- >> I=F1aki Baz Castillo >> >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ibc@aliax.net Wed May 25 05:57:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1FE06C6 for ; Wed, 25 May 2011 05:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTKClIllELK2 for ; Wed, 25 May 2011 05:57:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 96B9AE067C for ; Wed, 25 May 2011 05:57:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so6158690qwc.31 for ; Wed, 25 May 2011 05:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr3699943qcb.247.1306328258978; Wed, 25 May 2011 05:57:38 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 05:57:38 -0700 (PDT) In-Reply-To: <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> Date: Wed, 25 May 2011 14:57:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 12:57:40 -0000 2011/5/25 Adrian Georgescu : > Today SIP ALG breaks SIP most of the time. Actually I have never seen a s= ingle one that works and I deployed large SIP for 8 years now. They simply = mangle SIP headers without understanding that there is a state machine behi= nd. I started a wiki page about specific issues with SIP ALG routers: http://www.voip-info.org/wiki/view/Routers+SIP+ALG Please Christer, take a look to it and later tell me what I should expect about incoming MSRP-ALG routers. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 06:01:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0203713002E for ; Wed, 25 May 2011 06:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.813 X-Spam-Level: X-Spam-Status: No, score=-1.813 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KssTZkuyeU8u for ; Wed, 25 May 2011 06:01:24 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1F15F130026 for ; Wed, 25 May 2011 06:01:24 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 683E1B01BE; Wed, 25 May 2011 15:01:23 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 1F85AB0192; Wed, 25 May 2011 15:01:22 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=utf-8 From: Adrian Georgescu In-Reply-To: Date: Wed, 25 May 2011 15:01:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <209D1B93-F1CB-4DCE-A841-9D388F797ABA@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585 194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:01:25 -0000 Well Inaki, You should already reserve a placeholder there: http://www.voip-info.org/wiki/view/Routers+MSRP+ALG

Disaster in progress

Stay tuned for updates... Adrian On May 25, 2011, at 2:57 PM, I=C3=B1aki Baz Castillo wrote: > 2011/5/25 Adrian Georgescu : >> Today SIP ALG breaks SIP most of the time. Actually I have never seen = a single one that works and I deployed large SIP for 8 years now. They = simply mangle SIP headers without understanding that there is a state = machine behind. >=20 > I started a wiki page about specific issues with SIP ALG routers: >=20 > http://www.voip-info.org/wiki/view/Routers+SIP+ALG >=20 > Please Christer, take a look to it and later tell me what I should > expect about incoming MSRP-ALG routers. >=20 > --=20 > I=C3=B1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Wed May 25 06:03:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB813E067C for ; Wed, 25 May 2011 06:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=-0.314, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A-rI9NayI-E for ; Wed, 25 May 2011 06:03:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 06211E0655 for ; Wed, 25 May 2011 06:03:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ea-4ddcfe2d8816 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.E4.09774.D2EFCDD4; Wed, 25 May 2011 15:03:42 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 15:03:41 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 15:03:41 +0200 Thread-Topic: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 Thread-Index: Acwa2W3LA0lcteuUSh+/BE0Q1zFr0QAAHAew Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C871@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:03:43 -0000 Hi,=20 >>>>Based on Ben's WGLC comments, the current proposal is to have a=20 >>>>fallback mechanism as a STRONGLY RECOMMENDED. I don't mind having it ev= en stronger than that, but there ARE networks (e.g. defined by OMA) where=20 >>>>fallback will never be used, so for that reason I don't think we should= make it a MUST. >>> >>>Outside OMA/IMS world, there are millons of local or public (Internet)=20 >>>SIP networks, and usually commercial IP/TCP routers (those provided by t= he Internet Provider) come with builtin SIP ALG enabled by default. >>>If these vendors also include MSRP ALG and the fallback mechanism is not= a MUST, they wont implement such mechanism, so bye bye MSRP in "open"=20 >>>networks. >> >>So, how do these SIP ALGs behave today when it comes to MSRP? > >I don't know, I just hate SIP ALG's.=20 I thought you knew how 99% of the ALGs work... ;) >I would like SIP ALG's not no exist anymore as I don't want my router to i= nspect and modify my application layer data. Sessmatch is not going to either increase or decrease the number of ALGs, a= nd thinking so is naive in my personal opinon.=20 ALGs are deployed for many reasons (we can argue whether they are valid or = not, but that's another discussion) - reasons that in most cases have bigge= r priority than allowing MSRP traffic. Also note that sessmatch allows end-to-end TLS for MSRP, in which case the = ALG will not be able to inspect your data. Without sessmatch you don't have= that possibility, as an ALG must modify MSRP (without breaking it). The main reason for sessmatch is *not* to allow inspection of your data, bu= t rather to AVOID having to inspect and modify your data, and just treat it= as any other media. Most SIP ALGs today modify the SDP c/m-line, so MSRP is already broken. Not= even sessmatch will work with such ALGs.=20 Now, updating an ALG to modify the a=3Dpath attribute for MSRP is a relativ= ely easy task, compared to forcing them to be updated in order to process M= SRP media. It's not only about software, since some nodes may not even have= resources to do that. So, sessmatch provides a better chance of being able to do MSRP in networks= where ALGs are deployed. Sure, there are limitations, but sessmatch doesn'= t "break" anything that isn't already broken. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 06:10:05 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3191AE06C6 for ; Wed, 25 May 2011 06:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCMgRilwQBa1 for ; Wed, 25 May 2011 06:10:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B56B0E067C for ; Wed, 25 May 2011 06:10:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-98-4ddcffa9a0e5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.76.09774.9AFFCDD4; Wed, 25 May 2011 15:10:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 15:10:01 +0200 From: Christer Holmberg To: 'Adrian Georgescu' Date: Wed, 25 May 2011 15:10:01 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa2qd220zMyEXjQWGfwYlRwy5jlQAAYy+g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> In-Reply-To: <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:10:05 -0000 Hi,=20 >Today SIP ALG breaks SIP most of the time. Actually I have never seen a si= ngle one that works and I deployed large SIP for 8 years now. They simply=20 >mangle SIP headers without understanding that there is a state machine beh= ind. > >This is possible and easy when SIP signaling travels in clear text over UD= P, which is today most of the time as it was allowed unfortunately by the s= ame=20 >people that care about sess-match today. If traffic was TLS the ALGs would= have never existed today and SIP would just work today without the pains w= e=20 >have. > >So typically a programmer is hired for 4 hours to implement 'the SIP ALG f= eature' that a competitor has. He will write 4 lines of code without=20 >understanding the state machine of any protocol involved by doing a regexp= over clear text to replace strings in the sip packet. Then people crowd on= =20 >wikipedia to explain how to turn off the feature that breaks SIP. Sad. > >If you allow MSRP over TCP, same will happen all over again. > >Your draft explicitly creates the possibility for breaking MSRP sessions t= o pieces by intermediates. It was not possible before, now suddenly it is. = The=20 >experience shows that this will be abused simply by incompetence if nothin= g else to the extend that people will perceive that MSRP protocol does not = work=20 >and is broken. Same like SIP is today. I am not sure you answered my question, but I guess we can agree that most = SIP ALGs today will break MSRP. They will only modify the SDP c/m-line, and= they won't modify MSRP media content. So, sessmatch doesn't break anything that isn't already broken. On the other hand, sessmatch give a bigger chance of making MSRP to work in= scenarios with ALGs, as the only change needed is to modify the SDP a=3Dpa= th attribute. But, if you think that without sessmatch every ALG is going to implement MS= RP B2BUA functionality I guess we have completely different views of the wo= rld. The same if you think that without sessmatch people are going to remove the= ir ALGs, just to make MSRP work. Regards, Christer From ag@ag-projects.com Wed May 25 06:11:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0C3E0721 for ; Wed, 25 May 2011 06:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMKagqs0hhu7 for ; Wed, 25 May 2011 06:11:22 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 67A08E071A for ; Wed, 25 May 2011 06:11:22 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id ACF36B01BE; Wed, 25 May 2011 15:11:21 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 776EDB0192; Wed, 25 May 2011 15:11:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <4DDCE1DF.2050901@ericsson.com> Date: Wed, 25 May 2011 15:11:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54A780CB-4E3A-4B9B-95D3-14517FD45E0C@ag-projects.com> References: <4DDCE1DF.2050901@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:11:23 -0000 Hi Gonzallo, I am wondering. If the only applicability of sess-match is for deploying = a service behind an OMA style walled garden, why does it have to be an = IETF document about it? It can be an OMA or 3GPP specification, that is = fine. Is architecture in the end, how to use (or miss-use) existing = protocols for achieving some purpose, not a protocol specification. Why an IETF one that explicitly breaks what has already been created so = far? Creating a standard for how to insert intermediaries in a working = protocol? Leaving a door open for all possible problems that will emerge = out of this? This is not rhetorical, I just try to understand why a non-interoperable = standard with execrable security and integrity properties which has = nothing to do with public Internet is developed within the IETF? Isn't = it possible to just pass the ball away to where it belongs? OMA, 3GPP or = other organization that cares about it. Adrian On May 25, 2011, at 1:02 PM, Gonzalo Camarillo wrote: > Hi, >=20 > given that the backwards compatibility properties of this extension = have > caused some concern, the draft needs to do a better job describing = them. > Being explicit about them is important. The last paragraph of Section = 1 > should be edited so that it captures the different scenarios that have > been discussed on this list. The authors may even consider having a > brief section about backwards compatibility, which would also include > the comments about having to implement regular MRSP procedures as the > fall-back mechanism at a MUST or a SHOULD level (whatever the WG = decides). >=20 > Also, within that paragraph, the following sentence is confusing: >=20 >> MSRP entities that do not implement the sessmatch extension, and >> communicate with ALGs that do not implement MSRP B2BUA = functionality, >> can normally not establish MSRP sessions, since the session = matching >> will fail in case the address information of the SDP a=3Dpath = attribute >> has been modified by the ALGs. >=20 > That is not a standard scenario because before this extension was > defined, ALGs needed to implement MSRP B2BUA functionality. The draft > can say that this extension enables that scenario, but the draft = should > not talk about non-standard behavior in the context of backwards > compatibility because things can get quite confusing. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 >=20 > On 23/05/2011 6:51 PM, Ben Campbell wrote: >> This is a Working Group Last Call of = draft-ietf-simple-msrp-sessmatch-11: >>=20 >> http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11 >>=20 >> Please note that this draft contains substantial new text since = version 10, primarily concerning the use of an option tag. Even if you = were happy with version 10, please review this version. >>=20 >> The WGLC will conclude on 6 June 2011. Please send your comments, = including nits and "this is ready to go" type comments, to the authors = and the working group list. >>=20 >> Thanks! >>=20 >> Ben.=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From saul@ag-projects.com Wed May 25 06:14:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B998CE067C for ; Wed, 25 May 2011 06:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-CO+rgomt1I for ; Wed, 25 May 2011 06:14:14 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E66AE0655 for ; Wed, 25 May 2011 06:14:14 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AEFA2B01BF; Wed, 25 May 2011 15:14:13 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 14B02B0192; Wed, 25 May 2011 15:14:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:14:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:14:14 -0000 Hi, > I am not sure you answered my question, but I guess we can agree that = most SIP ALGs today will break MSRP. They will only modify the SDP = c/m-line, and they won't modify MSRP media content. >=20 > So, sessmatch doesn't break anything that isn't already broken. >=20 Since MSRP does not care about the c and m lines, if the recipient uses = a relay MSRP is not broken. Moreover, if the caller is not behind NAT = and ACM is being used it would also work, even without a relay.=20 Please explain what you mean by "already broken". Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed May 25 06:19:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779DEE07BC for ; Wed, 25 May 2011 06:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpYf4eCLAl1H for ; Wed, 25 May 2011 06:19:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E1361E0721 for ; Wed, 25 May 2011 06:19:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so6173447qwc.31 for ; Wed, 25 May 2011 06:19:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2940237qcb.285.1306329581347; Wed, 25 May 2011 06:19:41 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 06:19:41 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:19:41 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:19:42 -0000 2011/5/25 Christer Holmberg : > On the other hand, sessmatch give a bigger chance of making MSRP to work = in scenarios with ALGs, as the only change needed is to modify the SDP a=3D= path attribute. If an ALG modifies the SDP a=3Dpath attribute, it is because it wants to "solve the problem of the NAT", so it will also perform an ugly regexp over the SIP headers and break the signalling (in 99.99% of cases and scenarios). > But, if you think that without sessmatch every ALG is going to implement = MSRP B2BUA functionality I guess we have completely different views of the = world. > > The same if you think that without sessmatch people are going to remove t= heir ALGs, just to make MSRP work. Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG should not make a new specification to satisfy them when such new specification breaks the protocol itself (RFC 4975 and 4976). --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 06:21:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC0AE07E0 for ; Wed, 25 May 2011 06:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chV4Zs8Tv36q for ; Wed, 25 May 2011 06:21:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DE9C7E0721 for ; Wed, 25 May 2011 06:21:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-41-4ddd02621ae3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 6E.C9.09774.2620DDD4; Wed, 25 May 2011 15:21:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 15:21:38 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Wed, 25 May 2011 15:21:38 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa3aUdjvia/JFOSfqSGyH6Y/soFQAAC4LQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> In-Reply-To: <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:21:40 -0000 Hi,=20 >>I am not sure you answered my question, but I guess we can agree that mos= t SIP ALGs today will break MSRP. They will only modify the SDP c/m-line, a= nd=20 >>they won't modify MSRP media content. >=20 >>So, sessmatch doesn't break anything that isn't already broken. >=20 > >Since MSRP does not care about the c and m lines, if the recipient uses a = relay MSRP is not broken. Moreover, if the caller is not behind NAT and ACM= is=20 >being used it would also work, even without a relay.=20 I am not sure I understand. Could you please clarify. >Please explain what you mean by "already broken". Unless it is possible to make media by-pass the ALG (which I would assume i= s prevented in many cases), all media must be anchored by the ALG. That's t= he reason the ALG modifies the c/m-line. But, as the a=3Dpath attribute is = not modified, MSRP media won't be sent towards the ALG.=20 Regards, Christer From ag@ag-projects.com Wed May 25 06:25:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB2CE07F2 for ; Wed, 25 May 2011 06:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJTH3dGGo6JY for ; Wed, 25 May 2011 06:25:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id F11DBE06A8 for ; Wed, 25 May 2011 06:25:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 36546B01BE; Wed, 25 May 2011 15:25:05 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 50C3AB00E6; Wed, 25 May 2011 15:25:04 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-3--542294091 From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:25:03 +0200 Message-Id: <65945109-D02F-4E56-9479-DC0EDE41250D@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:25:08 -0000 --Apple-Mail-3--542294091 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An MSRP ALG label will cause vendors to jump on the 'we support that = too' train. This is why SIP ALGs don't work, nobody really needed those = boxes, nobody asked for them. Both end-users and service providers have = a NAT traversal solution in place, in their sip device. Nobody asked = the router manufacturers to build that feature. They did it because it = was possible (cleartext UDP) and they thought it is a differentiating = factor for their product. It was not, but now we all suffer because we = allowed it to happen. You created the same possibility for MSRP. If anyone can mangle the MSRP = packets, they will and all manufacturers will want to 'MSRP ALG enabled' = and will abuse this to the extend of rendering the original IETF = protocol specifications useless. Let me quote the mission of IETF: The mission of the IETF is to make the Internet work better by producing = high quality, relevant technical documents that influence the way people = design, use, and manage the Internet. sess-match does not fit the profile as a low quality hack and irrelevant = for the Internet in general. It serves a narrow purpose for walled = gardens outside of the Internet. This draft should be somewhere else, not in IETF.=20 Adrian On May 25, 2011, at 3:10 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> Today SIP ALG breaks SIP most of the time. Actually I have never seen = a single one that works and I deployed large SIP for 8 years now. They = simply=20 >> mangle SIP headers without understanding that there is a state = machine behind. >>=20 >> This is possible and easy when SIP signaling travels in clear text = over UDP, which is today most of the time as it was allowed = unfortunately by the same=20 >> people that care about sess-match today. If traffic was TLS the ALGs = would have never existed today and SIP would just work today without the = pains we=20 >> have. >>=20 >> So typically a programmer is hired for 4 hours to implement 'the SIP = ALG feature' that a competitor has. He will write 4 lines of code = without=20 >> understanding the state machine of any protocol involved by doing a = regexp over clear text to replace strings in the sip packet. Then people = crowd on=20 >> wikipedia to explain how to turn off the feature that breaks SIP. = Sad. >>=20 >> If you allow MSRP over TCP, same will happen all over again. >>=20 >> Your draft explicitly creates the possibility for breaking MSRP = sessions to pieces by intermediates. It was not possible before, now = suddenly it is. The=20 >> experience shows that this will be abused simply by incompetence if = nothing else to the extend that people will perceive that MSRP protocol = does not work=20 >> and is broken. Same like SIP is today. >=20 > I am not sure you answered my question, but I guess we can agree that = most SIP ALGs today will break MSRP. They will only modify the SDP = c/m-line, and they won't modify MSRP media content. >=20 > So, sessmatch doesn't break anything that isn't already broken. >=20 > On the other hand, sessmatch give a bigger chance of making MSRP to = work in scenarios with ALGs, as the only change needed is to modify the = SDP a=3Dpath attribute. >=20 > But, if you think that without sessmatch every ALG is going to = implement MSRP B2BUA functionality I guess we have completely different = views of the world. >=20 > The same if you think that without sessmatch people are going to = remove their ALGs, just to make MSRP work. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 --Apple-Mail-3--542294091 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii An = MSRP ALG label will cause vendors to jump on the 'we support that too' = train. This is why SIP ALGs don't work, nobody really needed those = boxes, nobody asked for them. Both end-users and service providers have = a NAT traversal solution in place, in their sip device.  Nobody = asked the router manufacturers to build that feature. They did it = because it was possible (cleartext UDP) and they thought it is a = differentiating factor for their product. It was not, but now we all = suffer because we allowed it to happen.


You = created the same possibility for MSRP. If anyone can mangle the MSRP = packets, they will and all manufacturers will want to 'MSRP ALG enabled' = and will abuse this to the extend of rendering the original IETF = protocol specifications useless.

Let me quote the mission of = IETF:

The mission of the IETF is to = make the Internet work better by producing high quality, relevant = technical documents that influence the way people design, use, and = manage the Internet.

sess-match does not fit the profile as a low = quality hack and irrelevant for the Internet in general. It serves a = narrow purpose for walled gardens outside of the = Internet.

This draft should be somewhere else, not in = IETF. 

<= /div>
Adrian

On May 25, 2011, at = 3:10 PM, Christer Holmberg wrote:


Hi,=

Today SIP ALG breaks SIP most of the = time. Actually I have never seen a single one that works and I deployed = large SIP for 8 years now. They simply
mangle SIP headers without understanding that there is a = state machine behind.

This is = possible and easy when SIP signaling travels in clear text over UDP, = which is today most of the time as it was allowed unfortunately by the = same
people that care about = sess-match today. If traffic was TLS the ALGs would have never existed = today and SIP would just work today without the pains we =
have.

So typically a = programmer is hired for 4 hours to implement 'the SIP ALG feature' that = a competitor has. He will write 4 lines of code without =
understanding the state = machine of any protocol involved by doing a regexp over clear text to = replace strings in the sip packet. Then people crowd on =
wikipedia to explain how to = turn off the feature that breaks SIP. Sad.

If you allow = MSRP over TCP, same will happen all over = again.

Your draft = explicitly creates the possibility for breaking MSRP sessions to pieces = by intermediates. It was not possible before, now suddenly it is. The =
experience shows that this = will be abused simply by incompetence if nothing else to the extend that = people will perceive that MSRP protocol does not work =
and is broken. Same like SIP = is today.

I am not sure you answered my question, = but I guess we can agree that most SIP ALGs today will break MSRP. They = will only modify the SDP c/m-line, and they won't modify MSRP media = content.

So, sessmatch doesn't break anything that isn't already = broken.

On the other hand, sessmatch give a bigger chance of = making MSRP to work in scenarios with ALGs, as the only change needed is = to modify the SDP a=3Dpath attribute.

But, if you think that = without sessmatch every ALG is going to implement MSRP B2BUA = functionality I guess we have completely different views of the = world.

The same if you think that without sessmatch people are = going to remove their ALGs, just to make MSRP = work.

Regards,

Christer



_____________________= __________________________
Simple mailing list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple


= = --Apple-Mail-3--542294091-- From saul@ag-projects.com Wed May 25 06:27:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1A3E0739 for ; Wed, 25 May 2011 06:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hIV9ov8+knv for ; Wed, 25 May 2011 06:27:21 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id CF620E0655 for ; Wed, 25 May 2011 06:27:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9E69BB01BE; Wed, 25 May 2011 15:27:19 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E4C22B00E6; Wed, 25 May 2011 15:27:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:27:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:27:21 -0000 >>=20 >> Since MSRP does not care about the c and m lines, if the recipient = uses a relay MSRP is not broken. Moreover, if the caller is not behind = NAT and ACM is=20 >> being used it would also work, even without a relay.=20 >=20 > I am not sure I understand. Could you please clarify. >=20 Alice is not behind NAT and sends an INVITE to Bob who is behind NAT. = With RFCs 4975 and 4976 this wouldn't work, but if the Alternate = Connection Model (RFC 6135) is being used Bob will make the TCP = connection to Alice, so no relay is needed at all. >> Please explain what you mean by "already broken". >=20 > Unless it is possible to make media by-pass the ALG (which I would = assume is prevented in many cases), all media must be anchored by the = ALG. That's the reason the ALG modifies the c/m-line. But, as the a=3Dpath= attribute is not modified, MSRP media won't be sent towards the ALG.=20 >=20 There is no standardized definition of what an ALG is nor what should = *exactly* do. You are assuming that all media must traverse this ALG or = else it will be blocked by a network element such as a firewall. That's = assuming too much. MSRP media can flow between even if SIP ALGs are = deployed only using already standardized techniques. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 06:28:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1EABE07F2 for ; Wed, 25 May 2011 06:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNRmuUAfUFNh for ; Wed, 25 May 2011 06:28:41 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CBF73E0655 for ; Wed, 25 May 2011 06:28:40 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-83-4ddd04074766 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 10.64.20773.7040DDD4; Wed, 25 May 2011 15:28:39 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 15:28:39 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 15:28:38 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa3mkqbISfRYNYTd+RyaECelhPZQAAFJMw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:28:41 -0000 Hi,=20 >>On the other hand, sessmatch give a bigger chance of making MSRP to work = in scenarios with ALGs, as the only change needed is to modify the SDP a=3D= path=20 >>attribute. > >If an ALG modifies the SDP a=3Dpath attribute, it is because it wants to "= solve the problem of the NAT", so it will also perform an ugly regexp over = the=20 >SIP headers and break the signalling (in 99.99% of cases and scenarios). And what does any of that have to do with sessmatch???????????????????????? Sessmatch is not the reason the ALG is deployed, and whatever other things = the ALG does it will do with or without sessmatch. >>But, if you think that without sessmatch every ALG is going to implement = MSRP B2BUA functionality I guess we have completely different views of the= =20 >>world. >> >>The same if you think that without sessmatch people are going to remove t= heir ALGs, just to make MSRP work. > >Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG shou= ld not make a new specification to satisfy them when such new specification= =20 >breaks the protocol itself (RFC 4975 and 4976). I think IETF SIMPLE WG should make specifications that can work in real-lif= e networks. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 06:35:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64742E073E for ; Wed, 25 May 2011 06:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+WY7mC3jS3z for ; Wed, 25 May 2011 06:35:27 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDE2E0655 for ; Wed, 25 May 2011 06:35:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-fc-4ddd059e4b7c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E8.96.20773.E950DDD4; Wed, 25 May 2011 15:35:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 15:35:26 +0200 From: Christer Holmberg To: 'Adrian Georgescu' Date: Wed, 25 May 2011 15:35:25 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa3ysbI6EwBZTiQy6UVX3dD05eqAAAJPuA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C875@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <65945109-D02F-4E56-9479-DC0EDE41250D@ag-projects.com> In-Reply-To: <65945109-D02F-4E56-9479-DC0EDE41250D@ag-projects.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-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:35:28 -0000 Hi, >An MSRP ALG label will cause vendors to jump on the 'we support that too' = train. This is why SIP ALGs don't work, nobody really needed those boxes,=20 >nobody asked for them. Both end-users and service providers have a NAT tra= versal solution in place, in their sip device. ALGs are also used for many other reasons than NAT traversal. >You created the same possibility for MSRP. If anyone can mangle the MSRP p= ackets, they will and all manufacturers will want to 'MSRP ALG enabled' and= =20 >will abuse this to the extend of rendering the original IETF protocol spec= ifications useless. Sessmatch allows you to do end-to-end TLS, without anyone mangling with you= r MSRP packets. And, IF someone really wants to mangle your packets, they can implement a d= edicated MSRP B2BUA for that. But, that's not the main reason people want s= essmatch. Regards, Christer From ibc@aliax.net Wed May 25 06:36:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567D1E07FD for ; Wed, 25 May 2011 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkCCAmyTLg5W for ; Wed, 25 May 2011 06:36:54 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id AC183E07FC for ; Wed, 25 May 2011 06:36:54 -0700 (PDT) Received: by qyk7 with SMTP id 7so5239738qyk.10 for ; Wed, 25 May 2011 06:36:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2955630qcb.285.1306330613834; Wed, 25 May 2011 06:36:53 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 06:36:53 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C871@ESESSCMS0356.eemea.ericsson.se> References: <4DDCE1DF.2050901@ericsson.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C86E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C871@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:36:53 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:36:55 -0000 2011/5/25 Christer Holmberg : > Sessmatch is not going to either increase or decrease the number of ALGs,= and thinking so is naive in my personal opinon. > > ALGs are deployed for many reasons (we can argue whether they are valid o= r not, but that's another discussion) - reasons that in most cases have big= ger priority than allowing MSRP traffic. > > Also note that sessmatch allows end-to-end TLS for MSRP, in which case th= e ALG will not be able to inspect your data. Without sessmatch you don't ha= ve that possibility, as an ALG must modify MSRP (without breaking it). > > The main reason for sessmatch is *not* to allow inspection of your data, = but rather to AVOID having to inspect and modify your data, and just treat = it as any other media. > > > Most SIP ALGs today modify the SDP c/m-line, so MSRP is already broken. N= ot even sessmatch will work with such ALGs. > > Now, updating an ALG to modify the a=3Dpath attribute for MSRP is a relat= ively easy task, compared to forcing them to be updated in order to process= MSRP media. It's not only about software, since some nodes may not even ha= ve resources to do that. > > So, sessmatch provides a better chance of being able to do MSRP in networ= ks where ALGs are deployed. Sure, there are limitations, but sessmatch does= n't "break" anything that isn't already broken. Hi Christer, I understand your point at 100%. To summarize: 1) SIP ALG's are a pain and should not exist. 2) But SIP ALG's do exist and we cannot change that, even less when router manufactures add it as a "feature" (by hiring an ignorant developer for 4 hours to make a regular expression if the destination port is 5060). 3) Routers with SIP ALG "could" work (just talking about signalling and RTP) as the specifications do not prevent it. But they fail in 99% of cases. 4) Routers with SIP-MSRP ALG *breaks* (yes or yes) the MSRP specification. 5) Anyhow router vendors wants to offer these ALG's. 6) IETF SIMPLE WG gets in action to save the world and publishes a specification to make such ALG's to work. The fact that the draft talks about "sessmatch" (instead of full URI matching) is just an anecdota as the mechanism is just needed when a non SIP/MSRP node (ALG box) wants to manipulate application layer data (SIP). If just pure SIP/MSRP nodes speak SIP and MSRP, "sessmatch" is not needed at all. 7) Such new specification breaks existing MSRP (as known in RFC 4975 and 4976). It makes router vendors happy, but corrupts the world. Given point 7, point 6 should not take place IMHO. I don't think IETF's business includes making happy to ignorant vendors. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 06:41:47 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC2FE07FD for ; Wed, 25 May 2011 06:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.987 X-Spam-Level: X-Spam-Status: No, score=-5.987 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJFJgoCPjk3k for ; Wed, 25 May 2011 06:41:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 613EEE07FC for ; Wed, 25 May 2011 06:41:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f4-4ddd0719616e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.CF.09774.9170DDD4; Wed, 25 May 2011 15:41:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 15:41:44 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Wed, 25 May 2011 15:41:44 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa33mTFuVfeRnjR+6CgpflpqrnMwAATXMA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.com> In-Reply-To: <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:41:47 -0000 Hi,=20 >>> Since MSRP does not care about the c and m lines, if the recipient=20 >>> uses a relay MSRP is not broken. Moreover, if the caller is not behind = NAT and ACM is being used it would also work, even without a relay. >>=20 >> I am not sure I understand. Could you please clarify. >=20 > >Alice is not behind NAT and sends an INVITE to Bob who is behind NAT. With= RFCs 4975 and 4976 this wouldn't work, but if the Alternate Connection Mod= el=20 >(RFC 6135) is being used Bob will make the TCP connection to Alice, so no = relay is needed at all. And what does that have to do with ALGs? Do you assume that an ALG is not n= eeded? If you assume that the ALG is only used for NAT traversal, that may = be true, but I don't think that's very common.=20 >>>Please explain what you mean by "already broken". >>=20 >>Unless it is possible to make media by-pass the ALG (which I would assume= is prevented in many cases), all media must be anchored by the ALG. That's= the=20 >>reason the ALG modifies the c/m-line. But, as the a=3Dpath attribute is n= ot modified, MSRP media won't be sent towards the ALG.=20 >=20 >There is no standardized definition of what an ALG is nor what should *exa= ctly* do. You are assuming that all media must traverse this ALG or else it= =20 >will be blocked by a network element such as a firewall. That's assuming t= oo much. MSRP media can flow between even if SIP ALGs are deployed only usi= ng=20 >already standardized techniques. I am making assumptions based on real-network experience. IF you can by-pass the ALG, then you may not need to go via the ALG in the = first place, and sessmatch doesn't cause any problems (sessmatch is compati= ble with 4975 when there are no ALGs between). Regards, Christer From ibc@aliax.net Wed May 25 06:44:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F130024 for ; Wed, 25 May 2011 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.31 X-Spam-Level: X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wq-cg-6uw5-p for ; Wed, 25 May 2011 06:44:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 661D2E0728 for ; Wed, 25 May 2011 06:44:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so6189893qwc.31 for ; Wed, 25 May 2011 06:44:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.71 with SMTP id fh7mr3851716qab.210.1306331078817; Wed, 25 May 2011 06:44:38 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 06:44:38 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:44:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:44:40 -0000 2011/5/25 Christer Holmberg : >>If an ALG modifies the SDP a=3Dpath attribute, it is because it wants to = "solve the problem of the NAT", so it will also perform an ugly regexp over= the >>SIP headers and break the signalling (in 99.99% of cases and scenarios). > > And what does any of that have to do with sessmatch??????????????????????= ?? Nothing, I just meant that, anyhow, a SIP ALG router will break SIP. > Sessmatch is not the reason the ALG is deployed. But ALG is the reason Sessmath is specified. >>Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG sho= uld not make a new specification to satisfy them when such new specificatio= n >>breaks the protocol itself (RFC 4975 and 4976). > > I think IETF SIMPLE WG should make specifications that can work in real-l= ife networks. I don't agree, not in this case. IP, UDP, TCP, TLS, SIP and MSRP just work. ALG's are not needed at all and break OSI/Internet layers. IETF should not product a specification for these horrible and undesirable "intermediaries" which, by nature, are invalid. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 06:48:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9740E07FD for ; Wed, 25 May 2011 06:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nXdYx8oxkFwm for ; Wed, 25 May 2011 06:48:04 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA0EE072C for ; Wed, 25 May 2011 06:48:04 -0700 (PDT) Received: by qyk29 with SMTP id 29so2535054qyk.10 for ; Wed, 25 May 2011 06:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr3759276qcb.171.1306331283562; Wed, 25 May 2011 06:48:03 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 06:48:03 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:48:03 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:48:04 -0000 2011/5/25 Christer Holmberg : > And what does that have to do with ALGs? Do you assume that an ALG is not= needed? If you assume that the ALG is only used for NAT traversal, that ma= y be true, but I don't think that's very common. Could you please detail other real usages of ALG (in SIP world). I've seen thousands of SIP-ALG routers and their only purpose is to "solve" the NAT issue (even if I don't need they to fix that). > sessmatch is compatible with 4975 when there are no ALGs between. That's a very cool way to say that sessmatch is not needed at all when there are no ALGs between. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 06:49:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC192E07FD for ; Wed, 25 May 2011 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl13rbuvQDYT for ; Wed, 25 May 2011 06:49:24 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5DFE07FC for ; Wed, 25 May 2011 06:49:24 -0700 (PDT) Received: by qyk29 with SMTP id 29so2535891qyk.10 for ; Wed, 25 May 2011 06:49:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2968191qcb.285.1306331363893; Wed, 25 May 2011 06:49:23 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 06:49:23 -0700 (PDT) In-Reply-To: <54A780CB-4E3A-4B9B-95D3-14517FD45E0C@ag-projects.com> References: <4DDCE1DF.2050901@ericsson.com> <54A780CB-4E3A-4B9B-95D3-14517FD45E0C@ag-projects.com> Date: Wed, 25 May 2011 15:49:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: Re: [Simple] WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:49:25 -0000 2011/5/25 Adrian Georgescu : > This is not rhetorical, I just try to understand why a non-interoperable = standard with execrable security and integrity properties which has nothing= to do with public Internet is developed within the IETF? Isn't it possible= to just pass the ball away to where it belongs? OMA, 3GPP or other organiz= ation that cares about it. 100% agreed. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Wed May 25 06:51:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDF0E07FD for ; Wed, 25 May 2011 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXwceYFkuUiO for ; Wed, 25 May 2011 06:51:39 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2597E072C for ; Wed, 25 May 2011 06:51:39 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DB712B01BE; Wed, 25 May 2011 15:51:38 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1D996B00E6; Wed, 25 May 2011 15:51:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 15:51:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8096A0C2-FC08-4147-BE52-C61760BEA337@ag-projects.com> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <356AD202-4B21-473B-B62B-2A1997B2 73A9@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:51:40 -0000 >>=20 >> Alice is not behind NAT and sends an INVITE to Bob who is behind NAT. = With RFCs 4975 and 4976 this wouldn't work, but if the Alternate = Connection Model=20 >> (RFC 6135) is being used Bob will make the TCP connection to Alice, = so no relay is needed at all. >=20 > And what does that have to do with ALGs? Do you assume that an ALG is = not needed? If you assume that the ALG is only used for NAT traversal, = that may be true, but I don't think that's very common.=20 >=20 I was just pointing out that a current ALG without MSRP knowledge will = not break MSRP. >> There is no standardized definition of what an ALG is nor what should = *exactly* do. You are assuming that all media must traverse this ALG or = else it=20 >> will be blocked by a network element such as a firewall. That's = assuming too much. MSRP media can flow between even if SIP ALGs are = deployed only using=20 >> already standardized techniques. >=20 > I am making assumptions based on real-network experience. >=20 Me too. I've tested some of the techniques used by ALGs and without = sessmatch nothing would work. I'm not assuming sessmatch will create = problems, I know it. > IF you can by-pass the ALG, then you may not need to go via the ALG in = the first place, and sessmatch doesn't cause any problems (sessmatch is = compatible with 4975 when there are no ALGs between). >=20 Because ALGs are traditionally deployed on walled gardens this doesn't = mean there is nothing outside.=20 If I'm outside your walled garden but I want to talk to you I will only = be able to do if I implement sessmatch myself or if your ALG supports = falling back to B2BUA mode. Since sessmatch is still not published, = forcing ALGs to fallback to B2BUA mode would solve all issues: users = inside the walled garden would use sessmatch, and people outside may = choose. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 06:51:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAA3E0816 for ; Wed, 25 May 2011 06:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.979 X-Spam-Level: X-Spam-Status: No, score=-5.979 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVWR2uZ8oFXF for ; Wed, 25 May 2011 06:51:51 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4BE0814 for ; Wed, 25 May 2011 06:51:50 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-6d-4ddd09759492 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A4.1B.20773.5790DDD4; Wed, 25 May 2011 15:51:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 15:51:50 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 15:51:49 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa4eaoURSyesarQVGtS+kRjH0oLQAAEbkw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:51:52 -0000 Hi,=20 >>>If an ALG modifies the SDP a=3Dpath attribute, it is because it wants to= =20 >>>"solve the problem of the NAT", so it will also perform an ugly regexp o= ver the SIP headers and break the signalling (in 99.99% of cases and=20 >>>scenarios). >> >>And what does any of that have to do with sessmatch??????????????????????= ?? > >Nothing, I just meant that, anyhow, a SIP ALG router will break SIP. Perhaps, but I think that discussion should take place elsewhere. >>Sessmatch is not the reason the ALG is deployed. > >But ALG is the reason Sessmath is specified. True.=20 But, ALGs are out there (whether we like it or not), and I am trying to mak= e something that has a bigger chance to work in scenarios where ALGs are de= ployed. >>>Routers vendors are the evil due to their SIP ALG. But IETF SIMPLE WG=20 >>>should not make a new specification to satisfy them when such new specif= ication breaks the protocol itself (RFC 4975 and 4976). >> >>I think IETF SIMPLE WG should make specifications that can work in real-l= ife networks. > >I don't agree, not in this case. > >IP, UDP, TCP, TLS, SIP and MSRP just work. ALG's are not needed at all and= break OSI/Internet layers. Well, there seem to be different opinions about that, but I don't think thi= s is the forum to discuss that. The FACT, which I base my work upon, is that the ALGs are out there, and fr= om experience I know they won't go away any time soon. I hope we can agree = on that :) >IETF should not product a specification for these=20 >horrible and undesirable "intermediaries" which, by nature, are invalid. I think IETF nowadays realizes the fact that ALGs are out there, and if pos= sible should be taken into consideration when specifying protocols. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 06:56:54 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A277AE0697 for ; Wed, 25 May 2011 06:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHNKxJyH2LiY for ; Wed, 25 May 2011 06:56:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DFB95E074E for ; Wed, 25 May 2011 06:56:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-05-4ddd0aa4c923 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.6C.20773.4AA0DDD4; Wed, 25 May 2011 15:56:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 15:56:50 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 15:56:51 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa4l8vB39BxTt0TDmjCKpZ5RK42gAAJgmQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C878@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <3E6CC4C3-5D7F-4F7F-A1E1-3E2AF2AAB574@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C873@ESESSCMS0356.eemea.ericsson.se> <6EE2CD62-E988-44A9-8DC4-06CBCA578C7F@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C876@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Cullen Jennings , "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 13:56:54 -0000 =20 Hi, >>And what does that have to do with ALGs? Do you assume that an ALG is not= needed? If you assume that the ALG is only used for NAT traversal, that ma= y be=20 >>true, but I don't think that's very common. > >Could you please detail other real usages of ALG (in SIP world). I've seen= thousands of SIP-ALG routers and their only purpose is to "solve" >the NAT issue (even if I don't need they to fix that). RFC 5853 (http://tools.ietf.org/rfc/rfc5853.txt) provides some information. There are also 3GPP documents. I can provide the links if you're interested= , but I think most is covered in RFC 5853. >>sessmatch is compatible with 4975 when there are no ALGs between. > >That's a very cool way to say that sessmatch is not needed at all when the= re are no ALGs between. Sure. Without ALGs, you don't need sessmatch. That's not Wikileaks material= - it has been public information from the beginning :) Regards, Christer From ag@ag-projects.com Wed May 25 07:01:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2595FE0728 for ; Wed, 25 May 2011 07:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNT6jN6SkfsP for ; Wed, 25 May 2011 07:01:01 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4AEE0714 for ; Wed, 25 May 2011 07:01:01 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id AAC0DB01BF; Wed, 25 May 2011 16:01:00 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id E2457B00E6 for ; Wed, 25 May 2011 16:00:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:00:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585 194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:01:02 -0000 >=20 > I think IETF nowadays realizes the fact that ALGs are out there, and = if possible should be taken into consideration when specifying = protocols. No, it does not . There is no specification for what an ALG is or does. It is an anomaly. = Is not a client, is not a server, is an intermediary that has no = business being there. The fact that it is, does not make it a legitimate = part of the picture. The whole justification of the existence of this draft is flawed. The = problem that it solves does not exit on the Internet. If implemented it = will break what was built so far on the Internet. Adrian From christer.holmberg@ericsson.com Wed May 25 07:02:18 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D816E06E9 for ; Wed, 25 May 2011 07:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2J3mxio3ift for ; Wed, 25 May 2011 07:02:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 99E09E0697 for ; Wed, 25 May 2011 07:02:17 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-36-4ddd0be89e36 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C4.26.09774.8EB0DDD4; Wed, 25 May 2011 16:02:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 16:02:16 +0200 From: Christer Holmberg To: 'Adrian Georgescu' , Simple WG Date: Wed, 25 May 2011 16:02:15 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa5DF6P+GT5VU8Rk+dl1Hy3kO+bAAABSMA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585 194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:02:18 -0000 So, why did we specify RFC 4976? I thought NATs are evil also...=20 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of= Adrian Georgescu Sent: 25. toukokuuta 2011 17:01 To: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch >=20 > I think IETF nowadays realizes the fact that ALGs are out there, and if p= ossible should be taken into consideration when specifying protocols. No, it does not . There is no specification for what an ALG is or does. It is an anomaly. Is = not a client, is not a server, is an intermediary that has no business bein= g there. The fact that it is, does not make it a legitimate part of the pic= ture. The whole justification of the existence of this draft is flawed. The probl= em that it solves does not exit on the Internet. If implemented it will bre= ak what was built so far on the Internet. Adrian _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From ibc@aliax.net Wed May 25 07:11:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6E8E06E9 for ; Wed, 25 May 2011 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.606 X-Spam-Level: X-Spam-Status: No, score=-2.606 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nodH0hEH7ZsS for ; Wed, 25 May 2011 07:11:32 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B5E2EE06FD for ; Wed, 25 May 2011 07:11:32 -0700 (PDT) Received: by qwc23 with SMTP id 23so6208935qwc.31 for ; Wed, 25 May 2011 07:11:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr2990501qcb.285.1306332692004; Wed, 25 May 2011 07:11:32 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 07:11:31 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:11:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:11:33 -0000 2011/5/25 Christer Holmberg : > So, why did we specify RFC 4976? I thought NATs are evil also... Right, but NAT exists for long time due to the not adoption of IPv6. IPv4 also specifies the existence of private IP ranges. Within IPv4, NAT is just an unavoidable reality and the specifications for IP protocols should take it into account (as IPv4 was also specified by IETF). But even with NAT, ALG's are not needed, they are boxes with no place in the whole picture and break OSI/Internet layers. In the case of MSRP we already have RFC 4976 to deal with NAT by respecting the existing specifications. Also don't forget that sessmatch draft (assuming it's used with ALG's) does break existing specifications. That is unnaceptable IMHO. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 07:21:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE6A013002F for ; Wed, 25 May 2011 07:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Tc2FhncAwHd for ; Wed, 25 May 2011 07:21:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 13A77130024 for ; Wed, 25 May 2011 07:21:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ac-4ddd1066a38f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.C2.20773.6601DDD4; Wed, 25 May 2011 16:21:27 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 16:21:26 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= Date: Wed, 25 May 2011 16:21:26 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa5adkOGraoB0nTyCAN3WY7HaahgAAQiwQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87B@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:21:29 -0000 Hi,=20 >Also don't forget that sessmatch draft (assuming it's used with ALG's) doe= s break existing specifications. That is unnaceptable IMHO. As I've said, it has limitations, but it is not going to make anything that= works today to not work. Sessmatch provides a bigger chance of making MSRP work with ALG's. Regards, Christer From ibc@aliax.net Wed May 25 07:24:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28308130039 for ; Wed, 25 May 2011 07:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrM0mVYzd7mM for ; Wed, 25 May 2011 07:24:45 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFC913002F for ; Wed, 25 May 2011 07:24:45 -0700 (PDT) Received: by qwc23 with SMTP id 23so6218778qwc.31 for ; Wed, 25 May 2011 07:24:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.203.71 with SMTP id fh7mr3893257qab.210.1306333484711; Wed, 25 May 2011 07:24:44 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 07:24:44 -0700 (PDT) Date: Wed, 25 May 2011 16:24:44 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Simple WG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:24:46 -0000 After long threads about issues with this draft, I'd would like to propose the following: - Rewrite the draft from scratch by just keeping the "sessmatch" mechanism itself (don't match full URI but just the sessmatch identifier in it). - Remove from the draft any mention to ALG's (as they shouldn't be considered in a IETF document, they are an "anomaly" in the IP world). - The draft would be 4-5 lines long. It would be very easy for all the implementations to update and support it. - Make the new RFC to update RFC 4975 and 4976. - Let OMA/RCS/IMS/3GPP (or any other walled warden in which a "presence" NOTIFY is charged to the user) specify in an own document the usage of ALG's and the changes to IETF's MSRP specs their devices must accomplish in order to work within their closed networks. - Promote the usage of IPv6 so this kind of aberrations won't take place anymore. - Ask the router manufactures not to include SIP and MSRP ALG "feature" in their boxes. - Promote the usage of SIP over TLS as router manufactures will still want a label "SIP+MSRP powered" in their products, and SIP over TLS is the only way to avoid them. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 07:27:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66264130043 for ; Wed, 25 May 2011 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhlLIRQerw2M for ; Wed, 25 May 2011 07:27:44 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id AFD9413002F for ; Wed, 25 May 2011 07:27:43 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id E5F49B01C2; Wed, 25 May 2011 16:27:42 +0200 (CEST) Received: from [192.168.1.161] (095-097-050-026.static.chello.nl [95.97.50.26]) by mail.sipthor.net (Postfix) with ESMTPSA id F1A87B0192; Wed, 25 May 2011 16:27:41 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87B@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:27:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFDA F5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:27:44 -0000 Bigger chance is a willing-full thought unsubstantiated by any = measurements. While breaking everything else is guaranteed. This does not form a good basis for improving how MSRP gets deployed. = The opposite goal will be achieved. MSRP will work so-so and only in = some walled garden places with certain solutions from certain vendors. = On the public Internet it will be broken by arbitrary ALGs that will = show up in the path without anyone being able to stop them. Is this what you want to achieve? On May 25, 2011, at 4:21 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> Also don't forget that sessmatch draft (assuming it's used with = ALG's) does break existing specifications. That is unnaceptable IMHO. >=20 > As I've said, it has limitations, but it is not going to make anything = that works today to not work. >=20 > Sessmatch provides a bigger chance of making MSRP work with ALG's. >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ben@estacado.net Wed May 25 07:28:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D6E130043 for ; Wed, 25 May 2011 07:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxBwGPN-CFAb for ; Wed, 25 May 2011 07:28:44 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84221130041 for ; Wed, 25 May 2011 07:28:43 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p4PESRAq081639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 09:28:33 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Wed, 25 May 2011 09:28:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFD! AF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Adrian Georgescu , Simple WG Subject: [Simple] Are we Really Talking about ALGs? (was Re: About draft-ietf-simple-sessmatch) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:28:50 -0000 (as individual) There's been a lot of conversation about how ALGs work (or don't work.) For the sake of discussion, keep in mind that the ALGs contemplated by = sessmatch are probably different than the ones that show up in every = random residential gateway. Sessmatch is worried about ALGs that also = perform media anchoring. The draft avoids the term SBC (probably to = avoid all the controversies surrounding them), but I think what we are = talking about is _exactly_ SBCs, and maybe the draft should acknowledge = that. I think in today's world, SBCs are as much about policy enforcement as = NAT traversal.=20 On May 25, 2011, at 9:11 AM, I=F1aki Baz Castillo wrote: > 2011/5/25 Christer Holmberg : >> So, why did we specify RFC 4976? I thought NATs are evil also... >=20 > Right, but NAT exists for long time due to the not adoption of IPv6. > IPv4 also specifies the existence of private IP ranges. Within IPv4, > NAT is just an unavoidable reality and the specifications for IP > protocols should take it into account (as IPv4 was also specified by > IETF). >=20 > But even with NAT, ALG's are not needed, they are boxes with no place > in the whole picture and break OSI/Internet layers. In the case of > MSRP we already have RFC 4976 to deal with NAT by respecting the > existing specifications. >=20 > Also don't forget that sessmatch draft (assuming it's used with ALG's) > does break existing specifications. That is unnaceptable IMHO. >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Wed May 25 07:31:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E16913004B for ; Wed, 25 May 2011 07:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiKhMTQWp71Y for ; Wed, 25 May 2011 07:31:54 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABDD130041 for ; Wed, 25 May 2011 07:31:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a4-4ddd12d9bdfc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E7.B5.20773.9D21DDD4; Wed, 25 May 2011 16:31:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 16:31:53 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= , Simple WG Date: Wed, 25 May 2011 16:31:52 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa54HbU/BA4bjFQ+2lJf0BcdkPqQAADmUA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:31:55 -0000 Hi,=20 >After long threads about issues with this draft, I'd would like to propose= the following: > >- Rewrite the draft from scratch by just keeping the "sessmatch" >mechanism itself (don't match full URI but just the sessmatch identifier i= n it). > >- Remove from the draft any mention to ALG's (as they shouldn't be conside= red in a IETF document, they are an "anomaly" in the IP world). ALGs are the main justification for sessmatch, so I have been asked to incl= ude that. If I remove it, what would your justification for sessmatch be? >- The draft would be 4-5 lines long. It would be very easy for all the imp= lementations to update and support it. > >- Make the new RFC to update RFC 4975 and 4976. There was a WG decission to NOT to that. Regards, Christer From saul@ag-projects.com Wed May 25 07:32:53 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525B1130049 for ; Wed, 25 May 2011 07:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm2VpzpvqErw for ; Wed, 25 May 2011 07:32:52 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 71A09130041 for ; Wed, 25 May 2011 07:32:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6FC6EB01C2; Wed, 25 May 2011 16:32:50 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id CBA26B0192; Wed, 25 May 2011 16:32:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 25 May 2011 16:32:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <434C21B8-F0B2-4F63-A058-A04D0AE79D11@ag-projects.com> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:32:53 -0000 On May 25, 2011, at 4:24 PM, I=F1aki Baz Castillo wrote: > After long threads about issues with this draft, I'd would like to > propose the following: >=20 > - Rewrite the draft from scratch by just keeping the "sessmatch" > mechanism itself (don't match full URI but just the sessmatch > identifier in it). >=20 > - Remove from the draft any mention to ALG's (as they shouldn't be > considered in a IETF document, they are an "anomaly" in the IP world). >=20 If we would do the above then there is no reason for the existence of = sessmatch. Sessmatch is needed by ALGs, so they need to be mentioned. As I said earlier, the only way I think everything will continue to work = is by making the fallback to B2BUA capability a MUST. This way ALGs and = users behind them will use sessmatch and whose who are outside may not, = but they would still interoperate. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ben@estacado.net Wed May 25 07:35:27 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0076F130049 for ; Wed, 25 May 2011 07:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZ6UHFsBc8SQ for ; Wed, 25 May 2011 07:35:26 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id ED915130041 for ; Wed, 25 May 2011 07:35:25 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p4PEZJKu083094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 09:35:23 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Wed, 25 May 2011 09:35:18 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:35:27 -0000 (as individual) On May 25, 2011, at 9:24 AM, I=F1aki Baz Castillo wrote: > After long threads about issues with this draft, I'd would like to > propose the following: >=20 > - Rewrite the draft from scratch by just keeping the "sessmatch" > mechanism itself (don't match full URI but just the sessmatch > identifier in it). >=20 > - Remove from the draft any mention to ALG's (as they shouldn't be > considered in a IETF document, they are an "anomaly" in the IP world). >=20 > - The draft would be 4-5 lines long. It would be very easy for all the > implementations to update and support it. Ironically, that's about where this started. The reason for the discussions about ALGs in the draft, was to motivate = the draft, and to attempt to show that current ALG/SBC behavior would = actually be helped by it. We have been hampered by the fact, as you = mention elsewhere, that there is no standard for ALGs or SBCs other than = defacto behavior. So, without documentation of assumptions about ALGs/SBCs, how do we = answer the following: 1) What problem does this draft attempt to solve? 2) Does this draft actually solve that problem? From ag@ag-projects.com Wed May 25 07:38:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA91E068D for ; Wed, 25 May 2011 07:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY-FLFdW0MY7 for ; Wed, 25 May 2011 07:38:11 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id BBF25E0655 for ; Wed, 25 May 2011 07:38:11 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D4B51B01BF; Wed, 25 May 2011 16:38:10 +0200 (CEST) Received: from [192.168.1.161] (095-097-050-026.static.chello.nl [95.97.50.26]) by mail.sipthor.net (Postfix) with ESMTPSA id 444D7B0192 for ; Wed, 25 May 2011 16:38:10 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:38:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:38:12 -0000 On May 25, 2011, at 4:31 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> After long threads about issues with this draft, I'd would like to = propose the following: >>=20 >> - Rewrite the draft from scratch by just keeping the "sessmatch" >> mechanism itself (don't match full URI but just the sessmatch = identifier in it). >>=20 >> - Remove from the draft any mention to ALG's (as they shouldn't be = considered in a IETF document, they are an "anomaly" in the IP world). >=20 > ALGs are the main justification for sessmatch, so I have been asked to = include that. >=20 > If I remove it, what would your justification for sessmatch be? >=20 None, actually. We tried to solve the wrong problem for the wrong = reasons in the wrong place, an IETF working Group. We failed. So what? = Better failing on doing it rather than succeeding and making everything = fall apart later. There is no excuse for breaking things when you know already your are = going to break them if you continue doing it. Now we have active MSRP deployments, when your draft started you thought = they were not going to be any MSRP 4975/4976 deployments any time soon. = Well, that assumption was wrong too. The fact that the WG took some decisions in the past, ALGs exists or = not, is not an excuse to demolish RFC 4975 and 4976 that work just fine. Adrian From christer.holmberg@ericsson.com Wed May 25 07:38:54 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9038E06FD for ; Wed, 25 May 2011 07:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.128 X-Spam-Level: X-Spam-Status: No, score=-6.128 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96TfdsXVMzC0 for ; Wed, 25 May 2011 07:38:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7F7E06DA for ; Wed, 25 May 2011 07:38:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-0d-4ddd147d5fd1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.E0.09774.D741DDD4; Wed, 25 May 2011 16:38:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 16:38:51 +0200 From: Christer Holmberg To: 'Adrian Georgescu' Date: Wed, 25 May 2011 16:38:51 +0200 Thread-Topic: [Simple] About draft-ietf-simple-sessmatch Thread-Index: Acwa5+kXgJNgvHGSQoCV4yuaTjB+/QAALaew Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87D@ESESSCMS0356.eemea.ericsson.se> References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFDA F5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:38:55 -0000 Hi,=20 >Bigger chance is a willing-full thought unsubstantiated by any measurement= s. While breaking everything else is guaranteed. Again, what does it break, that isn't already broken? >This does not form a good basis for improving how MSRP gets deployed. That's your opinion.=20 In my expereince the customer interest in MSRP has gone up dramtically due = to sessmatch, as not having to deploy MSRP specific relays, and/or ALG+MSRP= B2BUA will generate big savings. >The opposite goal will be achieved. MSRP will work so-so and only in some = walled=20 >garden places with certain solutions from certain vendors. On the public I= nternet it will be broken by arbitrary ALGs that will show up in the path=20 >without anyone being able to stop them. ALGs will show up with or without sessmatch. The question is how big the ef= fort would be for them to support MSRP. >Is this what you want to achieve? I want to achieve MSRP becoming a success, by being deployed also in other = networks than the ones you are referring to. Regards, Christer On May 25, 2011, at 4:21 PM, Christer Holmberg wrote: >=20 > Hi, >=20 >> Also don't forget that sessmatch draft (assuming it's used with ALG's) d= oes break existing specifications. That is unnaceptable IMHO. >=20 > As I've said, it has limitations, but it is not going to make anything th= at works today to not work. >=20 > Sessmatch provides a bigger chance of making MSRP work with ALG's. >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ag@ag-projects.com Wed May 25 07:44:00 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F658E07E5 for ; Wed, 25 May 2011 07:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xY+QpE+fQ4j8 for ; Wed, 25 May 2011 07:43:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6C95CE07E0 for ; Wed, 25 May 2011 07:43:59 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CDDF8B01BE; Wed, 25 May 2011 16:43:58 +0200 (CEST) Received: from [192.168.1.161] (095-097-050-026.static.chello.nl [95.97.50.26]) by mail.sipthor.net (Postfix) with ESMTPSA id BBB62B0192 for ; Wed, 25 May 2011 16:43:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87D@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:43:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <025C82B4-2E10-4849-9C8F-6014FFDA F5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C877@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87A@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87D@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:00 -0000 The places where this can get deployed, do not need an IETF endorsement. = Those bodies will make an internal note/document which becomes mandatory = for their vendor supply chain. There are many changes already described = in SIP, XCAP and other protocols in those walled gardens. We do not need to pass an IETF document to break exiting well = established MSRP protocols proven to be working fine for this. OMA/3GPP can simply make a change to exiting MSRP protocol to have their = walled gardens implemented. If they ever want to get out of their walled = garden, their vendor must deploy a gateway to Internet. Is very simple = stuff. No need to break the Internet.=20 Adrian On May 25, 2011, at 4:38 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> Bigger chance is a willing-full thought unsubstantiated by any = measurements. While breaking everything else is guaranteed. >=20 > Again, what does it break, that isn't already broken? >=20 >> This does not form a good basis for improving how MSRP gets deployed. >=20 > That's your opinion.=20 >=20 > In my expereince the customer interest in MSRP has gone up dramtically = due to sessmatch, as not having to deploy MSRP specific relays, and/or = ALG+MSRP B2BUA will generate big savings. >=20 >> The opposite goal will be achieved. MSRP will work so-so and only in = some walled=20 >> garden places with certain solutions from certain vendors. On the = public Internet it will be broken by arbitrary ALGs that will show up in = the path=20 >> without anyone being able to stop them. >=20 > ALGs will show up with or without sessmatch. The question is how big = the effort would be for them to support MSRP. >=20 >> Is this what you want to achieve? >=20 > I want to achieve MSRP becoming a success, by being deployed also in = other networks than the ones you are referring to. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On May 25, 2011, at 4:21 PM, Christer Holmberg wrote: >=20 >>=20 >> Hi, >>=20 >>> Also don't forget that sessmatch draft (assuming it's used with = ALG's) does break existing specifications. That is unnaceptable IMHO. >>=20 >> As I've said, it has limitations, but it is not going to make = anything that works today to not work. >>=20 >> Sessmatch provides a bigger chance of making MSRP work with ALG's. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Wed May 25 07:44:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED41E07EC for ; Wed, 25 May 2011 07:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.425 X-Spam-Level: X-Spam-Status: No, score=-6.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x34sqwnc3KeQ for ; Wed, 25 May 2011 07:44:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A3EB1E07EA for ; Wed, 25 May 2011 07:44:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-5e-4ddd15b06914 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.32.09774.0B51DDD4; Wed, 25 May 2011 16:44:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 16:44:00 +0200 From: Christer Holmberg To: 'Adrian Georgescu' , Simple WG Date: Wed, 25 May 2011 16:44:00 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa6WIoohDtR2wjQqSeJv6twWJfkwAAEpdA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> In-Reply-To: <915A0224-794F-4587-942D-0A58548E679A@ag-projects.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:06 -0000 Hi,=20 >>> After long threads about issues with this draft, I'd would like to prop= ose the following: >>>=20 >>> - Rewrite the draft from scratch by just keeping the "sessmatch" >>> mechanism itself (don't match full URI but just the sessmatch identifie= r in it). >>>=20 >>> - Remove from the draft any mention to ALG's (as they shouldn't be cons= idered in a IETF document, they are an "anomaly" in the IP world). >>=20 >> ALGs are the main justification for sessmatch, so I have been asked to i= nclude that. >>=20 >> If I remove it, what would your justification for sessmatch be? >>=20 > >None, actually. We tried to solve the wrong problem for the wrong reasons = in the wrong place, an IETF working Group. We failed. So what? Better faili= ng=20 >on doing it rather than succeeding and making everything fall apart later. We are solving the problem where ALGs have to act as MSRP B2BUAs in order t= o support anchoring of MSRP media, and I have seen no failure. >There is no excuse for breaking things when you know already your are goin= g to break them if you continue doing it. It's not going to break anything that isn't already broken. >Now we have active MSRP deployments, when your draft started you thought t= hey were not going to be any MSRP 4975/4976 deployments any time soon. Well= ,=20 >that assumption was wrong too. > >The fact that the WG took some decisions in the past, ALGs exists or not, = is not an excuse to demolish RFC 4975 and 4976 that work just fine. I am not suggesting to demolish anything. RFC 4975 and 4976 does not work fine with ALGs. Regards, Christer From saul@ag-projects.com Wed May 25 07:44:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650D9E06BA for ; Wed, 25 May 2011 07:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LONfzecooWlY for ; Wed, 25 May 2011 07:44:31 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E915F13003F for ; Wed, 25 May 2011 07:44:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 5723EB01C2; Wed, 25 May 2011 16:44:30 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 30AF2B0192; Wed, 25 May 2011 16:44:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> Date: Wed, 25 May 2011 16:44:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8B54CD2B-6CCE-41A3-B811-88ACA7DCDCCA@ag-projects.com> References: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:31 -0000 >=20 > Ironically, that's about where this started. >=20 > The reason for the discussions about ALGs in the draft, was to = motivate the draft, and to attempt to show that current ALG/SBC behavior = would actually be helped by it. We have been hampered by the fact, as = you mention elsewhere, that there is no standard for ALGs or SBCs other = than defacto behavior. >=20 > So, without documentation of assumptions about ALGs/SBCs, how do we = answer the following: >=20 > 1) What problem does this draft attempt to solve? None. If we consider ALGs, then the answer would be the manufacturers = inability to implement the right solution, that is, a B2BUA for MSRP. > 2) Does this draft actually solve that problem? >=20 If we consider there is a problem in point 1), partially, since it adds = new problems. 3) Does this draft introduce any new problems? Yes. I breaks interoperability with RFC 4975/4976 endpoints. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed May 25 07:44:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442F4130056 for ; Wed, 25 May 2011 07:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9IgvEvQ7qak for ; Wed, 25 May 2011 07:44:37 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCB5130057 for ; Wed, 25 May 2011 07:44:37 -0700 (PDT) Received: by qyk29 with SMTP id 29so2572194qyk.10 for ; Wed, 25 May 2011 07:44:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr3802772qcb.247.1306334676549; Wed, 25 May 2011 07:44:36 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 07:44:36 -0700 (PDT) In-Reply-To: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> References: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> Date: Wed, 25 May 2011 16:44:36 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:38 -0000 2011/5/25 Ben Campbell : >> - The draft would be 4-5 lines long. It would be very easy for all the >> implementations to update and support it. > > Ironically, that's about where this started. > > The reason for the discussions about ALGs in the draft, was to motivate t= he draft, and to attempt to show that current ALG/SBC behavior would actual= ly be helped by it. We have been hampered by the fact, as you mention elsew= here, that there is no standard for ALGs or SBCs other than defacto behavio= r. > > So, without documentation of assumptions about ALGs/SBCs, how do we answe= r the following: > > 1) What problem does this draft attempt to solve? > 2) Does this draft actually solve that problem? Yes, you all are 100% right here. My motivations are the following: - It's true (in fact I've said it before several times) that Sessmatch is useless if we ignore ALG's. I just proposed to make it a standard (which supposes 4 lines of code in each MSRP entity) to allow OMA/RCS/3GPP to make usage of it within their networks and their specifications. - ALG's will break RFC 4975 and 4976 (when acting as ALG's) so it doesn't matter the existence of an IETF spec describing it. Don't let the vendors say "Yes, I break MSRP but I'm based on a RFC". Of course I could be wrong and my suggestion be just a stupid proposal, sur= e :) --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 07:44:52 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063D5E0743 for ; Wed, 25 May 2011 07:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EXqR8FcNRJg for ; Wed, 25 May 2011 07:44:51 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7232413005A for ; Wed, 25 May 2011 07:44:51 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id D77B5B01BE; Wed, 25 May 2011 16:44:50 +0200 (CEST) Received: from [192.168.1.161] (095-097-050-026.static.chello.nl [95.97.50.26]) by mail.sipthor.net (Postfix) with ESMTPSA id 2BD27B019A; Wed, 25 May 2011 16:44:49 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Adrian Georgescu In-Reply-To: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> Date: Wed, 25 May 2011 16:44:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9C833783-2D41-412D-835B-B3563FBEF509@ag-projects.com> References: <1EDEE9D1-19E8-4FE5-83B4-2B6C8F324764@estacado.net> To: Ben Campbell X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:44:52 -0000 The places where this proposed draft can see deployments is only in = walled gardens that do not need an IETF endorsement. Those bodies can = make an internal note/document which becomes mandatory for their vendor = supply chain. There are many changes already described in SIP, XCAP and = other protocols in those walled gardens. We do not need to pass an IETF document to break exiting well = established MSRP protocols proven to be working fine for this. OMA/3GPP can simply make a change to exiting MSRP protocol to have their = walled gardens implemented. If they ever want to get out of their walled = garden, their vendor must deploy a gateway to Internet. This does not break anything. On May 25, 2011, at 4:35 PM, Ben Campbell wrote: > (as individual) >=20 > On May 25, 2011, at 9:24 AM, I=F1aki Baz Castillo wrote: >=20 >> After long threads about issues with this draft, I'd would like to >> propose the following: >>=20 >> - Rewrite the draft from scratch by just keeping the "sessmatch" >> mechanism itself (don't match full URI but just the sessmatch >> identifier in it). >>=20 >> - Remove from the draft any mention to ALG's (as they shouldn't be >> considered in a IETF document, they are an "anomaly" in the IP = world). >>=20 >> - The draft would be 4-5 lines long. It would be very easy for all = the >> implementations to update and support it. >=20 > Ironically, that's about where this started. >=20 > The reason for the discussions about ALGs in the draft, was to = motivate the draft, and to attempt to show that current ALG/SBC behavior = would actually be helped by it. We have been hampered by the fact, as = you mention elsewhere, that there is no standard for ALGs or SBCs other = than defacto behavior. >=20 > So, without documentation of assumptions about ALGs/SBCs, how do we = answer the following: >=20 > 1) What problem does this draft attempt to solve? > 2) Does this draft actually solve that problem? >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ag@ag-projects.com Wed May 25 07:47:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081B8130066 for ; Wed, 25 May 2011 07:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Unwp3WpY-V7t for ; Wed, 25 May 2011 07:47:40 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2C13003F for ; Wed, 25 May 2011 07:47:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9A6CFB0192; Wed, 25 May 2011 16:47:39 +0200 (CEST) Received: from [192.168.1.161] (095-097-050-026.static.chello.nl [95.97.50.26]) by mail.sipthor.net (Postfix) with ESMTPSA id 02BDFB0192; Wed, 25 May 2011 16:47:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:47:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <20391EC5-78FB-47B9-84FA-1D39F4B22F90@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:47:41 -0000 > RFC 4975 and 4976 does not work fine with ALGs. This is not an excuse to break the RFCs. This should open your eyes that = the ALGs must disappear not otherwise. These things cannot cohabit together.=20 This is IETF and the RFCs work just fine. The ALGs do not belong here, take the problem some places else. Adrian From saul@ag-projects.com Wed May 25 07:49:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D0B13006C for ; Wed, 25 May 2011 07:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-y1KL1vRRuY for ; Wed, 25 May 2011 07:49:40 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B44813006B for ; Wed, 25 May 2011 07:49:40 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CDBC3B01BE; Wed, 25 May 2011 16:49:39 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 4EB82B0192; Wed, 25 May 2011 16:49:39 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 16:49:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 14:49:41 -0000 >=20 > RFC 4975 and 4976 does not work fine with ALGs. >=20 Since the behavior for an ALG is not specified anywhere how can you = ensure that? A vendor could very well use a SIP ALG and a MSRP Relay and = there would be no issues. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 08:06:06 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B21E0750 for ; Wed, 25 May 2011 08:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt5NXS49WzBA for ; Wed, 25 May 2011 08:06:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 32ACFE0720 for ; Wed, 25 May 2011 08:06:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-3e-4ddd1adcf7e1 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DB.97.09774.CDA1DDD4; Wed, 25 May 2011 17:06:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 17:06:03 +0200 From: Christer Holmberg To: 'Adrian Georgescu' Date: Wed, 25 May 2011 17:06:02 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa6rMZ27XjEiCfSHSZascoCZr5owAAbF2w Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C880@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <20391EC5-78FB-47B9-84FA-1D39F4B22F90@ag-projects.com> In-Reply-To: <20391EC5-78FB-47B9-84FA-1D39F4B22F90@ag-projects.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-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:06:06 -0000 =20 >>RFC 4975 and 4976 does not work fine with ALGs. > >This is not an excuse to break the RFCs.=20 I am not breaking the RFCc. I am defining an extension which will not break= anything that works today. >This should open your eyes that the ALGs must disappear not otherwise. It doesn't matter what my eyes see - ALGs will not disappear. >These things cannot cohabit together.=20 > >This is IETF and the RFCs work just fine. > >The ALGs do not belong here, take the problem some places else. It belongs in draft-ietf-simple-msrp-sessmatch.=20 Regards, Christer From christer.holmberg@ericsson.com Wed May 25 08:09:03 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573AAE0750 for ; Wed, 25 May 2011 08:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuDTbN-b8BiE for ; Wed, 25 May 2011 08:09:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8087BE0720 for ; Wed, 25 May 2011 08:09:02 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-86-4ddd1b8d890d Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.1F.20773.D8B1DDD4; Wed, 25 May 2011 17:09:01 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 17:09:01 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Wed, 25 May 2011 17:09:00 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa6vnt27A6IeeBRNCZzQ/eCUcPtQAAlaUQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C881@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:09:03 -0000 Hi,=20 >>RFC 4975 and 4976 does not work fine with ALGs. >=20 >Since the behavior for an ALG is not specified anywhere how can you ensure= that? A vendor could very well use a SIP ALG and a MSRP Relay and there wo= uld=20 >be no issues. >From my experience, I know that most ALGs don't implement MSRP B2BUA functi= onality. I also know that customers don't want to deploy MSRP specific relays - at l= east not if they also provide other types of media. But, I'm happy to be proven wrong. Regards, Christer From ag@ag-projects.com Wed May 25 08:10:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75227E07EF for ; Wed, 25 May 2011 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWkI36Bz1bi1 for ; Wed, 25 May 2011 08:10:14 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D5AF4E07EC for ; Wed, 25 May 2011 08:10:13 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 1D098B01BE; Wed, 25 May 2011 17:10:12 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 6D9EFB0192; Wed, 25 May 2011 17:10:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C880@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 17:10:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <20391EC5-78FB-47B9-84FA-1D39F4B22F90@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C880@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:10:14 -0000 This draft should not exist. It solves no Internet related problem. It = solves particular interests of some walled-garden providers not = connected to the Internet. IETF has nothing to do with this. On May 25, 2011, at 5:06 PM, Christer Holmberg wrote: >=20 >=20 >>> RFC 4975 and 4976 does not work fine with ALGs. >>=20 >> This is not an excuse to break the RFCs.=20 >=20 > I am not breaking the RFCc. I am defining an extension which will not = break anything that works today. >=20 >> This should open your eyes that the ALGs must disappear not = otherwise. >=20 > It doesn't matter what my eyes see - ALGs will not disappear. >=20 >> These things cannot cohabit together.=20 >>=20 >> This is IETF and the RFCs work just fine. >>=20 >> The ALGs do not belong here, take the problem some places else. >=20 > It belongs in draft-ietf-simple-msrp-sessmatch.=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From saul@ag-projects.com Wed May 25 08:16:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AFAE07F3 for ; Wed, 25 May 2011 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.655 X-Spam-Level: X-Spam-Status: No, score=-1.655 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07eP+c+K9kmE for ; Wed, 25 May 2011 08:16:59 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 48416E0750 for ; Wed, 25 May 2011 08:16:59 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 90818B01C3; Wed, 25 May 2011 17:16:58 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id EBC29B00E6; Wed, 25 May 2011 17:16:45 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C881@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 17:16:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7B9BF8E5-FC1B-449A-989B-0639AD8EE37C@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C881@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:16:59 -0000 >>=20 >> Since the behavior for an ALG is not specified anywhere how can you = ensure that? A vendor could very well use a SIP ALG and a MSRP Relay and = there would=20 >> be no issues. >=20 > =46rom my experience, I know that most ALGs don't implement MSRP B2BUA = functionality. >=20 > I also know that customers don't want to deploy MSRP specific relays - = at least not if they also provide other types of media. >=20 > But, I'm happy to be proven wrong. >=20 Can you ensure this will always be true? No. So the specification needs = to take the case I described into account. The breakage this draft = introduces is severe enough not to base decisions on what anyone may = think about what customers want. They may want something else tomorrow. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ag@ag-projects.com Wed May 25 08:19:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 566DBE075A for ; Wed, 25 May 2011 08:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1hcIxCwp8eG for ; Wed, 25 May 2011 08:19:58 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 06957E0750 for ; Wed, 25 May 2011 08:19:58 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 45EB8B01C2; Wed, 25 May 2011 17:19:57 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id E1715B00E6 for ; Wed, 25 May 2011 17:19:55 +0200 (CEST) From: Adrian Georgescu Content-Type: multipart/alternative; boundary=Apple-Mail-5--535402450 Date: Wed, 25 May 2011 17:19:55 +0200 Message-Id: <2B3A46AA-FD95-4383-BDD9-720465F74E04@ag-projects.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] MSRP ACM and File Transfer Open Source implementation X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:19:59 -0000 --Apple-Mail-5--535402450 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-2 Hello, We have released today in the open source domain both client and server = implementation for multiparty push and pull File Transfers (RFC5547) and = MSRP ACM support (RFC6135) This completes a several years journey related to implementing the MSRP = protocol, which a key ingredient in developing SIP applications beyond = VoIP.=20 All MSRP client and server software components have been implemented = successfully and are available in the Open Source domain: - MSRP Client Library http://download.ag-projects.com/MSRP/ - MSRP Relay http://msrprelay.org/ - MSRP Chat Server http://sylkserver.com All client feature are built into Blink SIP client: Blink http://icanblink.com Their correspondent IETF standards are: MSRP protocol RFC4975 MSRP relay extension RFC4976 MSRP File Transfer RFC5547 MSRP Alternative Connection Model RFC6135 MSRP switch draft-ietf-simple-chat-08 Indication of Message Composition RFC3994 CPIM Message Format RFC3862 Conference event package RFC4575 A Framework for Conferencing with SIP RFC4353 Conferencing for User Agents RFC4579 MSRP media plane is a perfect companion for RTP, which is used for audio = and video streams. It is a key ingredient for leveraging the real power = of SIP protocol that few have exploited so far. MSRP provides connection = oriented media stream, reliable connectivity, delivery reports, TLS = encryption and works excellent in NATed environments. Other vendors are = moving into the same direction by adding MSRP capabilities to their SIP = solutions.=20 Today we are using MSRP successfully for applications beyond Voice over = IP like Instant Messaging, File Transfers and Desktop Sharing. Other = applications that need a direct reliable connection between SIP = end-points can easily achieve this over an MSRP connection. Using SIP = SIMPLE client SDK one can use just a few lines of code to enable MSRP = transport for a SIP end-point. Many thanks to all that helped us on the way, especially our main = sponsor NLnet foundation http://nlnet.nl and IETF that managed to = produce a standard that works well. The following people authored the software: Adrian Georgescu Dan Pascu Denis Bilenko Luci Stanescu Ruud Klaver Sa=FAl Ibarra Special thanks to Henry Sinnreich, Alan B. Jonhston, Robert J. Sparks = for their relentless mentoring, their patience with the young apprentice = and for writing the great SIP Beyond VoIP book: = http://www.amazon.com/SIP-Beyond-VoIP-Communications-Revolution/dp/0974813= 001 Regards, Adrian --Apple-Mail-5--535402450 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-2 http://download.ag-projects= .com/MSRP/
- MSRP Relay   http://msrprelay.org/
- = MSRP Chat Server    http://sylkserver.com

All client feature are built into Blink SIP = client:


Their correspondent IETF standards are:
  • MSRP protocol RFC4975
  • MSRP relay = extension RFC4976
  • MSRP File Transfer RFC5547
  • MSRP = Alternative Connection Model RFC6135
  • MSRP switch = draft-ietf-simple-chat-08
  • Indication of Message Composition = RFC3994
  • CPIM Message Format RFC3862
  • Conference event = package RFC4575
  • A Framework for Conferencing with SIP = RFC4353
  • Conferencing for User Agents = RFC4579
MSRP media plane is a perfect = companion for RTP, which is used for audio and video streams. It is a = key ingredient for leveraging the real power of SIP protocol that few = have exploited so far. MSRP provides connection oriented media = stream, reliable connectivity, delivery reports, TLS encryption and = works excellent in NATed environments. Other vendors are moving into the = same direction by adding MSRP capabilities to their SIP = solutions. 

Today we are using MSRP = successfully for applications beyond Voice over IP like Instant = Messaging, File Transfers and Desktop Sharing.  Other applications = that need a direct reliable connection between SIP end-points can easily = achieve this over an MSRP connection. Using SIP SIMPLE client SDK one = can use just a few lines of code to enable MSRP transport for a SIP = end-point.

Many thanks to all that helped us on = the way, especially our main sponsor NLnet foundation http://nlnet.nl and IETF that managed = to produce a standard that works well.

The = following people authored the software:

Adrian = Georgescu
Dan Pascu
Denis = Bilenko
Luci Stanescu
Ruud = Klaver
Sa=FAl = Ibarra

Special thanks to Henry =  Sinnreich, Alan B. Jonhston, Robert J. Sparks for their relentless = mentoring, their patience with the young apprentice and for writing the = great SIP Beyond VoIP book:


Regards,
Adrian


= --Apple-Mail-5--535402450-- From christer.holmberg@ericsson.com Wed May 25 08:34:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3AD13005C for ; Wed, 25 May 2011 08:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNHRfnjKvfBR for ; Wed, 25 May 2011 08:34:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD65130057 for ; Wed, 25 May 2011 08:34:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-43-4ddd219ca019 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2E.3E.09774.C912DDD4; Wed, 25 May 2011 17:34:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 17:34:52 +0200 From: Christer Holmberg To: 'Adrian Georgescu' Date: Wed, 25 May 2011 17:34:51 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa7dkZSUKr3lkKRgSiYFYpByfrAAAAw/lA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C882@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <20391EC5-78FB-47B9-84FA-1D39F4B22F90@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C880@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:34:55 -0000 >This draft should not exist. It solves no Internet related problem. It sol= ves particular interests of some walled-garden providers not connected to t= he=20 >Internet. > >IETF has nothing to do with this. In this case, there is nothing which prevents what we specify to be used ou= tside "walled gardens". In general, there is also an agreement between 3GPP and IETF that you may w= ant to take a look at. Regards, Christer On May 25, 2011, at 5:06 PM, Christer Holmberg wrote: >=20 >=20 >>> RFC 4975 and 4976 does not work fine with ALGs. >>=20 >> This is not an excuse to break the RFCs.=20 >=20 > I am not breaking the RFCc. I am defining an extension which will not bre= ak anything that works today. >=20 >> This should open your eyes that the ALGs must disappear not otherwise. >=20 > It doesn't matter what my eyes see - ALGs will not disappear. >=20 >> These things cannot cohabit together.=20 >>=20 >> This is IETF and the RFCs work just fine. >>=20 >> The ALGs do not belong here, take the problem some places else. >=20 > It belongs in draft-ietf-simple-msrp-sessmatch.=20 >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Wed May 25 08:39:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD5613004F for ; Wed, 25 May 2011 08:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIE69gg6wS71 for ; Wed, 25 May 2011 08:39:57 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 74707130035 for ; Wed, 25 May 2011 08:39:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-b8-4ddd22cc8353 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.7F.09774.CC22DDD4; Wed, 25 May 2011 17:39:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 17:39:55 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?=27Sa=FAl_Ibarra_Corretg=E9=27?= Date: Wed, 25 May 2011 17:39:54 +0200 Thread-Topic: [Simple] Suggestion for sessmatch draft Thread-Index: Acwa7sqhR/9IcDMsQwWVMl38e1l8iwAAoKPA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C883@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C881@ESESSCMS0356.eemea.ericsson.se> <7B9BF8E5-FC1B-449A-989B-0639AD8EE37C@ag-projects.com> In-Reply-To: <7B9BF8E5-FC1B-449A-989B-0639AD8EE37C@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:39:58 -0000 =20 >>> Since the behavior for an ALG is not specified anywhere how can you=20 >>> ensure that? A vendor could very well use a SIP ALG and a MSRP Relay an= d there would be no issues. >>=20 >> From my experience, I know that most ALGs don't implement MSRP B2BUA fun= ctionality. >>=20 >> I also know that customers don't want to deploy MSRP specific relays - a= t least not if they also provide other types of media. >>=20 >> But, I'm happy to be proven wrong. >=20 >Can you ensure this will always be true?=20 Of course not. But, I do know that it is true for now, and will be true for= a considerable time to come - at a time when people are requesting the fun= ctionality. And, if people then in future suddenly start to deploy MSRP B2BUAs things w= hill still work. >No. So the specification needs to take the case I described into account. = The breakage this draft introduces is severe enough not to base decisions o= n=20 >what anyone may think about what customers want. They may want something e= lse tomorrow. I still doesn't think it breaks anything that isn't broken already. Regards, Christer From saul@ag-projects.com Wed May 25 08:45:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88ED130055 for ; Wed, 25 May 2011 08:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04JvA5avfnhZ for ; Wed, 25 May 2011 08:45:38 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5122A130035 for ; Wed, 25 May 2011 08:45:38 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7452FB00E6; Wed, 25 May 2011 17:45:37 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D25A6B00E6; Wed, 25 May 2011 17:45:35 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C883@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 17:45:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87C@ESESSCMS0356.eemea.ericsson.se> <915A0224-794F-4587-942D-0A58548E679A@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C87E@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C881@ESESSCMS0356.eemea.ericsson.se> <7B9BF8E5-FC1B-449A-989B-0639AD8EE37C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C883@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: 'Adrian Georgescu' , Simple WG Subject: Re: [Simple] Suggestion for sessmatch draft X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 15:45:39 -0000 >=20 > Of course not. But, I do know that it is true for now, and will be = true for a considerable time to come - at a time when people are = requesting the functionality. >=20 Then lets make a solution that works for all. > And, if people then in future suddenly start to deploy MSRP B2BUAs = things whill still work. >=20 >> No. So the specification needs to take the case I described into = account. The breakage this draft introduces is severe enough not to base = decisions on=20 >> what anyone may think about what customers want. They may want = something else tomorrow. >=20 > I still doesn't think it breaks anything that isn't broken already. >=20 I strongly disagree. If a ALG modifies the SDP in whatever way without = touching the path line it will just work with 4975/4976, today. The fact = that some networks where ALGs are deployed block direct traffic is not = relevant, that's a network issue, not related to what the ALG does. -- Sa=FAl Ibarra Corretg=E9 AG Projects From adam@nostrum.com Wed May 25 09:25:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A2E0820 for ; Wed, 25 May 2011 09:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaoO4Jyivz3r for ; Wed, 25 May 2011 09:25:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49465E0817 for ; Wed, 25 May 2011 09:25:13 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4PGPB1H017828 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 25 May 2011 11:25:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DDD2D67.3000708@nostrum.com> Date: Wed, 25 May 2011 11:25:11 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:25:14 -0000 I'm somewhat sad that the experience of implementors (Adrian, Saúl) have borne out the warnings that Cullen and I attempted to sound back in 2008. We pointed out how this mechanism fundamentally breaks the existing protocol. And, despite all the work that has gone into this, it's still broken. You can't just change the bits around the edges of the protocol and make it somehow more palatable: the actual thesis of the document *is* the problem. Let's take a step back and address a few of the points that have come up. On 5/25/11 6:29 AM, Christer Holmberg wrote: > there ARE networks (e.g. defined by OMA) where fallback will never be used, so for that reason I don't think we should make it a MUST. These networks tend to start out as islands, and eventually morph into something that desperately *wants* to be connected to the Internet. Think of how WAP/WML portals eventually gave way to actual HTTP access to web sites. It is the height or naïvité to believe any IP technology that starts as a walled garden stays a walled garden forever. Because of this, the Internet community as a whole has a stake in how things are done inside the walled gardens. We don't want architecturally unsound decisions to leak out into the Internet when the wall is breached. On 5/25/11 8:51 AM, Christer Holmberg wrote: > I think IETF nowadays realizes the fact that ALGs are out there, and if possible should be taken into consideration when specifying protocols. Having been at this for almost 15 years, I'm sympathetic to some of the arguments about designing protocols that don't work in the face of NATs, firewalls, and similar intermediaries. I'm familiar with the pain of having to clean up the messes that result from designing protocols that actually don't work in real deployments. This situation, however, isn't about not working. It's about not being *optimal* for the intermediaries. As everyone is aware, we already have two ways to skin this particular cat (MSRP relays, MSRP B2BUA SBCs). The proposed mechanism expands the set of solutions from "recommended" and "not recommended" to "recommended," "not recommended," and "actually breaks stuff." That's actually a pretty big deal, and I don't think most people completely understand this. What this draft proposes is a non-backwards-compatible change to an existing protocol to *OPTIMIZE* for an architecture that the IETF actively discourages. The only -- ONLY -- purpose of this draft is to enable devices designed to usurp informed consent to do so at a greater scale. On 5/25/11 9:44 AM, Christer Holmberg wrote: > RFC 4975 and 4976 does not work fine with ALGs. That's the most hilarious tail-wagging-the-dog statement I've heard in a long, long time. Let me fix that for you. "ALGs that can't be bothered to implement some modicum of actual MSRP functionality don't work with MSRP." Now, *that* is true. But I don't see why we're even considering introducing backwards-compatibility problems to OPTIMIZE (not enable, but actually optimize) the job of these intermediaries. Especially when (1) the intermediaries operate without the consent of the end user, and (2) we already have a mechanism for NAT and policy enforcement point traversal that *does* acquire user consent. I see no way a draft designed to optimize the network for behaviors that the IETF does not condone has any hope of passing IETF last call, much less the IESG. /a From christer.holmberg@ericsson.com Wed May 25 09:47:09 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C510DE082D for ; Wed, 25 May 2011 09:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycJ6r+ljxDTr for ; Wed, 25 May 2011 09:47:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C4947E0756 for ; Wed, 25 May 2011 09:47:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-1e-4ddd328ba39d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C1.0D.09774.B823DDD4; Wed, 25 May 2011 18:47:07 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 18:47:04 +0200 From: Christer Holmberg To: Adam Roach , "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" Date: Wed, 25 May 2011 18:47:03 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: Acwa+FkjRSEn28wwTUKoI4ILae5MCwAAGtoQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> In-Reply-To: <4DDD2D67.3000708@nostrum.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 16:47:09 -0000 Hi Adam, >I'm somewhat sad that the experience of implementors (Adrian,=20 >Sa=FAl) have borne out the warnings that Cullen and I attempted=20 >to sound back in 2008. We pointed out how this mechanism=20 >fundamentally breaks the existing protocol. And, despite all=20 >the work that has gone into this, it's still broken. You=20 >can't just change the bits around the edges of the protocol=20 >and make it somehow more palatable: the actual thesis of the=20 >document *is* the problem. > =20 >Let's take a step back and address a few of the points that=20 >have come up. >=20 >On 5/25/11 6:29 AM, Christer Holmberg wrote: >>there ARE networks (e.g. defined by OMA) where fallback=20 >>will never be used, so for that reason I don't think we=20 >>should make it a MUST. >=20 >These networks tend to start out as islands, and eventually=20 >morph into something that desperately *wants* to be connected=20 >to the Internet.=20 >Think of how WAP/WML portals eventually gave way to actual=20 >HTTP access to web sites. It is the height or na=EFvit=E9 to=20 >believe any IP technology that starts as a walled garden=20 >stays a walled garden forever. Because of this, the Internet=20 >community as a whole has a stake in how things are done=20 >inside the walled gardens. We don't want architecturally=20 >unsound decisions to leak out into the Internet when the wall=20 >is breached. > >>I think IETF nowadays realizes the fact that ALGs are out=20 >>there, and if possible should be taken into consideration=20 >>when specifying protocols. >=20 >Having been at this for almost 15 years, I'm sympathetic to=20 >some of the arguments about designing protocols that don't=20 >work in the face of NATs, firewalls, and similar=20 >intermediaries. I'm familiar with the pain of having to clean=20 >up the messes that result from designing protocols that=20 >actually don't work in real deployments. >=20 >This situation, however, isn't about not working. It's about not being >*optimal* for the intermediaries. As everyone is aware, we=20 >already have two ways to skin this particular cat (MSRP=20 >relays, MSRP B2BUA SBCs). The proposed mechanism expands the=20 >set of solutions from "recommended" and "not recommended" to=20 >"recommended," "not recommended," and "actually breaks stuff." >=20 >That's actually a pretty big deal, and I don't think most=20 >people completely understand this. >=20 >What this draft proposes is a non-backwards-compatible change=20 >to an existing protocol to *OPTIMIZE* for an architecture=20 >that the IETF actively discourages. The only -- ONLY --=20 >purpose of this draft is to enable devices designed to usurp=20 >informed consent to do so at a greater scale. What is non-backwards-compatible? =20 >On 5/25/11 9:44 AM, Christer Holmberg wrote: >>RFC 4975 and 4976 does not work fine with ALGs. >=20 >That's the most hilarious tail-wagging-the-dog statement I've=20 >heard in a long, long time. Let me fix that for you. "ALGs=20 >that can't be bothered to implement some modicum of actual=20 >MSRP functionality don't work with MSRP."=20 I guess you could put it that way, but I don't agree with the "can't be bot= hered" statement. There are reasons (related to finance, resources etc) why= they haven't done it. If it was only about a piece of software I don't think there would be any i= ssues. >Now, *that* is true. But I don't see why we're even considering introducin= g=20 >backwards-compatibility problems to OPTIMIZE (not enable, but=20 >actually optimize) the job of these intermediaries. Especially when >(1) the intermediaries operate without the consent of the end=20 >user, and >(2) we already have a mechanism for NAT and policy=20 >enforcement point traversal that *does* acquire user consent. >=20 >I see no way a draft designed to optimize the network for=20 >behaviors that the IETF does not condone has any hope of=20 >passing IETF last call, much less the IESG. Is that a general comment, or you objecting to the draft moving forward? Regards, Christer From christer.holmberg@ericsson.com Wed May 25 10:07:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA15E0694 for ; Wed, 25 May 2011 10:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.14 X-Spam-Level: X-Spam-Status: No, score=-6.14 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcVGUdkO0r4E for ; Wed, 25 May 2011 10:07:37 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AF6D3E06A8 for ; Wed, 25 May 2011 10:07:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-c6-4ddd3756ce3b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.21.09774.6573DDD4; Wed, 25 May 2011 19:07:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 19:07:33 +0200 From: Christer Holmberg To: Shida Schubert , Simple WG Date: Wed, 25 May 2011 19:07:30 +0200 Thread-Topic: WGLC Comments on draft-ietf-simple-sessmatch-11 - Shida's comments Thread-Index: AcwaoJglFC/5BcVRRCOn7hArL9KI8wAXKWWA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7EF@ESESSCMS0356.eemea.ericsson.se> References: In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Shida's comments X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:07:38 -0000 =20 Hi Shida, >I have read the previous draft and had no issues with the=20 >previous draft but I have re-reviewed the draft once again=20 >and below are my comments.=20 >=20 >I only have minor comments and I think the document is ready=20 >to proceed. >=20 >Minor concern/clarification ---------- =20 > 1. SIP-identity is used here and there, is it the RFC4744 or=20 > something else? > If it is RFC4744, I don't know why it can't be used. If=20 > the ALG is behind the authentication server defined in RFC4744 then S= IP-identity=20 > should be able to function.=20 Yes, when the draft mentions "SIP Identity" it refers to RFC4474. We can be= more clear about that.=20 It is true as you say that SIP identity based SDP integrity protection will= work for cases where the ALG is located between MSRP UA and the authentica= tion proxy. While this then works for ALGs that are built into firewalls, i= t is however not the case for the type of ALGs used by SIP network provider= s to handle policy control, intercept, QoS monitoring, address domain bridg= ing, transcoding, etc. These are often located on the other side of the aut= henticating proxy and in these networks SIP Identity is commonly not suppor= ted at all.=20 One suggestion woudl be to remove this issue conmpletely, by changing the d= raft to say that if TLS authentication using pre-shared key is not possible= , then the UAs shall use the RFC4975 specified authentication. Ie, we will = completely remove the text regarding concern of useage of fingerprint witho= ut integrity protection.=20 ---------- > 2. There is a mention of option-tag usage in Require in response but > there is no mentioning of its use in Require in request. I=20 > have no strong opinion against this, but if it is feasible to use it = in=20 > response, I don't see why it wouldn't be the case for request.=20 I don't think that the requester should ever insert Require:sessmatch, sinc= e it can not know on beforehand whether it will be needed. ---------- > Nits:=20 > =20 > 1. Abstract > remove "of MSRP entities" >=20 > 2. Abstract > add '' to sessmatch after "option-tag, ".=20 >=20 > 3. Introduction > OLD : "in order to match an MSRP message to an MSRP=20 > session. That requires consistency between" >=20 > NEW :"in order to match an MSRP message to an MSRP session,=20 > which requires consistency between" >=20 > 4. Introduction > OLD : "The reason is that the matching of an MSRP message=20 > to an ongoing session will not fail" >=20 > NEW : "The reason is that the matching of an MSRP message to=20 > an ongoing session will not fail because there is no entity=20 > modifying the SDP." >=20 > 5. Introduction > OLD : "MSRP B2BUA functionality, can normally not establish=20 > MSRP sessions" >=20 > NEW : "MSRP B2BUA functionality, can not normally establish=20 > MSRP sessions" >=20 > 6. Applicability Statement > OLD : "where ALGs that might modify the address information=20 > of the SDP a=3Dpath attribute, but do not implement MSRP B2BUA=20 > functionality, are present." >=20 > NEW : "where ALGs are present that might modify the address=20 > information of the SDP a=3Dpath attribute, but do not implement=20 > MSRP B2BUA functionality." >=20 > 7. Session Matching > OLD : "and the one defined in this specification for the=20 > sessmatch extension," > =20 > NEW : "and the one defined in this specification," >=20 > 8. Session Matching > OLD : "while the mechanism in RFC 4975 uses the MSRP URI=20 > comparison rules for " >=20 > NEW : "while the mechanism in RFC 4975 uses the entire MSRP=20 > URI comparison rules for=20 >=20 > 9. Session Matchin > OLD : "If a match exists, the entity MUST assume that the=20 > host that formed the connection is the host to which this URI=20 > was given." > =20 > NEW : "If a match exists, the entity MUST assume that the=20 > host that formed the connection to, is the host to which this=20 > URI was given." >=20 > 10. Session Matching > OLD : "The entity MUST also check to make sure the session=20 > is not already " >=20 > NEW : "The entity MUST also check to make sure the=20 > session-id is not already " >=20 > 11. Usage of 'sessmatch' option-tag > OLD : "INVITE request contains the 'sessmatch' option-tag=20 > in the Supported header field of the response," >=20 > NEW : "INVITE request contains the 'sessmatch' option-tag=20 > in the Supported header field," >=20 > 12. Usage of 'sessmatch' option-tag > OLD : "in order to anchor and forward MSRP traffic, but=20 > will not be able to perform" >=20 > NEW : "in order to anchor and forward MSRP traffic, but=20 > unable to perform" >=20 > 13. Usage of 'sessmatch' option-tag > OLD : "and therfore sends a 420 (Not Supported) response to=20 > the INVITE request, is outside the scope of this specification." >=20 > NEW : "and sending a 420 (Not Supported) response to the=20 > INVITE request, is outside the scope of this specification." >=20 > 14. MSRP awareness > The MSRP communication. Is this supposed to be MSRP session?=20 > * I forgot the difference between MSRP session and MSRP=20 > communication.. The terminology > is used interchangeably throughout the draft. I guess I can=20 > look at the RFC4975 and remind myself of the difference..=20 >=20 > 15. TCP connection reuse > OLD : "MSRP payload might not enable re-usage of TCP connections" >=20 > NEW : "MSRP payload might not enable reuse of TCP connections" >=20 > 16. Is the Relay extension a Normative reference, shouldn't=20 > it be Informative? Also if the=20 > SIP Identity based SDP protection refers to "RFC4474" then=20 > I think it should be added=20 > to the reference as well.=20 I'll take a closer look at your nits comments later, but after a first look= they seem fine. Thanks! Best regards, Christer From ibc@aliax.net Wed May 25 10:17:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4130EE06D0 for ; Wed, 25 May 2011 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVGV3Jee5BZy for ; Wed, 25 May 2011 10:17:16 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9BED9E068C for ; Wed, 25 May 2011 10:17:16 -0700 (PDT) Received: by qyk7 with SMTP id 7so5382036qyk.10 for ; Wed, 25 May 2011 10:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr3190247qcb.285.1306343836047; Wed, 25 May 2011 10:17:16 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 10:17:15 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 19:17:15 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:17:17 -0000 2011/5/25 Christer Holmberg : > What is non-backwards-compatible? An MSRP endpoint implementing this draft behind a MSRP-ALG cannot talk with a MSRP endpoint not implementing it (RFC 4975 broken), neither with a MSRP relay (RFC 4976 broken). TLS name based authentication (as RFC 4975/4976 allows) broken. Also, even in the abscense of an ALG, an MSRP entity implementing sessmatch could decide to change the URI in a MSRP message by keeping the session id fragment, so if the remote peer doesn't implement sessionmatch the protocol would fail. Is it not enough? Could we already agree that seematch breaks backwards-compatibility? or not yet? Yes, I do know that anyhow a MSRP-ALG (implementing sessionmatch or not) will break MSRP (as you have argumented several times). But I don't care such ALG boxes, neither I think IETF's business includes standarizing those ALG's, even less when it involves breaking an existing protocol and existing implementations. > I guess you could put it that way, but I don't agree with the "can't be b= othered" statement. There are reasons (related to finance, resources etc) w= hy they haven't done it. > If it was only about a piece of software I don't think there would be any= issues. So IETF should product specifications taking into account vendors finances, is it? And what about the finances and resources of the implementors who have already implemented MSRP RFC 4975 and 4976 by respecting the OSI/Internet layers and the existing specifications? I know *no* SIP provider relying on SIP-ALG capable routers in customer side. Most of the SIP providers fix NAT in server side (rtp-proxies, Comedia mode) or encourage standard solutions as STUN/ICE, but no one relies on SIP-ALG routers. As Adrian pointed out before, nobody has demanded routers vendors to include SIP-ALG, but they include it anyway, maybe for announcing a "SIP powered" label in the box. Why would it be different for MSRP? why MSRP-ALG's are so needed for vendors now? (the best reason is not enough to break a protocol). Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 10:46:15 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D14E06E0 for ; Wed, 25 May 2011 10:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RWwBM17fwib for ; Wed, 25 May 2011 10:46:14 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8252DE06A1 for ; Wed, 25 May 2011 10:46:14 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-76-4ddd406472ec Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AC.7E.20773.4604DDD4; Wed, 25 May 2011 19:46:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 19:46:12 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 19:46:10 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: Acwa/5lh/n8q+4EZR6WWglLqmwSFMwAAgL9A Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 17:46:16 -0000 Hi, >>What is non-backwards-compatible? >=20 >An MSRP endpoint implementing this draft behind a MSRP-ALG=20 >cannot talk with a MSRP endpoint not implementing it (RFC=20 >4975 broken), neither with a MSRP relay (RFC 4976 broken).=20 >TLS name based authentication (as RFC 4975/4976 allows) broken. And, how is that different from an MSRP endpoint NOT implementing the draft= behind a MSRP-ALG? >Also, even in the abscense of an ALG, an MSRP entity=20 >implementing sessmatch could decide to change the URI in a=20 >MSRP message by keeping the session id fragment, so if the=20 >remote peer doesn't implement sessionmatch the protocol would fail. That can be fixed by explicitly forbidding it. >Is it not enough? Could we already agree that seematch breaks=20 >backwards-compatibility? or not yet? I can agree with the TLS name based authentication part. =20 >Yes, I do know that anyhow a MSRP-ALG (implementing sessionmatch or >not) will break MSRP (as you have argumented several times).=20 And I will keep repeating it. >But I don't care such ALG boxes, neither I think IETF's=20 >business includes standarizing those ALG's, even less when it=20 >involves breaking an existing protocol and existing implementations. Implementations in networks with these kind of ALGs are already broken. >>I guess you could put it that way, but I don't agree with=20 >>the "can't be bothered" statement. There are reasons (related=20 >>to finance, resources etc) why they haven't done it. >>If it was only about a piece of software I don't think=20 >>there would be any issues. >=20 >So IETF should product specifications taking into account=20 >vendors finances, is it? And what about the finances and=20 >resources of the implementors who have already implemented=20 >MSRP RFC 4975 and 4976 by respecting the OSI/Internet layers=20 >and the existing specifications? If their deployments work fine, they don't need to bother. They will even w= ork with sessmatch clients. >I know *no* SIP provider relying on SIP-ALG capable routers=20 >in customer side. Most of the SIP providers fix NAT in server=20 >side (rtp-proxies, Comedia mode) or encourage standard=20 >solutions as STUN/ICE, but no one relies on SIP-ALG routers.=20 I can ensure you that is not true. And, again, it's not only about NAT. >As Adrian pointed out before, nobody has demanded routers=20 >vendors to include SIP-ALG, but they include it anyway, maybe=20 >for announcing a "SIP powered" label in the box. That is Adrian's opinion. And, if you think that customers are so stupid that they are going to pay f= or things they don't need, we for sure are not talking about the same custo= mers... >Why would it be different for MSRP? why MSRP-ALG's are so needed for=20 >vendors now? (the best reason is not enough to break a protocol). They are needed by vendors so that vendors can provide them to customers wh= o require them. Regards, Christer From ibc@aliax.net Wed May 25 11:14:10 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B92E0756 for ; Wed, 25 May 2011 11:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuCR3Lq0JBb1 for ; Wed, 25 May 2011 11:14:09 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 507D2E0717 for ; Wed, 25 May 2011 11:14:09 -0700 (PDT) Received: by qwc23 with SMTP id 23so6380577qwc.31 for ; Wed, 25 May 2011 11:14:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr4023551qcb.247.1306347248795; Wed, 25 May 2011 11:14:08 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 11:14:08 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 20:14:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:14:10 -0000 2011/5/25 Christer Holmberg : >>>What is non-backwards-compatible? >> >>An MSRP endpoint implementing this draft behind a MSRP-ALG >>cannot talk with a MSRP endpoint not implementing it (RFC >>4975 broken), neither with a MSRP relay (RFC 4976 broken). >>TLS name based authentication (as RFC 4975/4976 allows) broken. > > And, how is that different from an MSRP endpoint NOT implementing the dra= ft behind a MSRP-ALG? MSRP would also be broken if two users not implementing the draft try to talk through a MSRP-ALG so, where is the problem? In the MSRP-ALG. The draft would solve nothing in this case, neither it's guilty of the issue caused by the ALG but, why should a RFC legitimize these ALG's and their wrong behaviour? >>Yes, I do know that anyhow a MSRP-ALG (implementing sessionmatch or >>not) will break MSRP (as you have argumented several times). > > And I will keep repeating it. I know :) >>But I don't care such ALG boxes, neither I think IETF's >>business includes standarizing those ALG's, even less when it >>involves breaking an existing protocol and existing implementations. > > Implementations in networks with these kind of ALGs are already broken. Yes, but now you want to document such aberrantion and make it a standard. >>So IETF should product specifications taking into account >>vendors finances, is it? And what about the finances and >>resources of the implementors who have already implemented >>MSRP RFC 4975 and 4976 by respecting the OSI/Internet layers >>and the existing specifications? > > If their deployments work fine, they don't need to bother. They will even= work with sessmatch clients. The difference is that they should be supposed to work in *any* correct and standarized scenario. But now with ALG's and this draft standarizing them, they will just work in same cases (when there is not an ALG). --=20 I=C3=B1aki Baz Castillo From adam@nostrum.com Wed May 25 11:19:41 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE08E0756 for ; Wed, 25 May 2011 11:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yC0NWnykNilq for ; Wed, 25 May 2011 11:19:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 92E99E0717 for ; Wed, 25 May 2011 11:19:40 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4PIJaRU028164 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 May 2011 13:19:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DDD4838.6090904@nostrum.com> Date: Wed, 25 May 2011 13:19:36 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:19:41 -0000 On 5/25/11 11:47 AM, Christer Holmberg wrote: > >> I see no way a draft designed to optimize the network for >> behaviors that the IETF does not condone has any hope of >> passing IETF last call, much less the IESG. > Is that a general comment, or you objecting to the draft moving forward? I've never stopped objecting to the draft moving forward. /a From christer.holmberg@ericsson.com Wed May 25 11:27:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E763913007B for ; Wed, 25 May 2011 11:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOBBsxtWFEo6 for ; Wed, 25 May 2011 11:27:36 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1453513003D for ; Wed, 25 May 2011 11:27:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-12-4ddd4a1639f5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1B.7F.09774.61A4DDD4; Wed, 25 May 2011 20:27:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 20:27:33 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 20:27:31 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbB4wq4I+6k/mUTCObh36g3VpncgAACQZA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C805@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:27:37 -0000 Hi,=20 >>>>What is non-backwards-compatible? >>>> >>>>An MSRP endpoint implementing this draft behind a MSRP-ALG=20 >>>>cannot talk=20 >>>>with a MSRP endpoint not implementing it (RFC >>>>4975 broken), neither with a MSRP relay (RFC 4976 broken). >>>>TLS name based authentication (as RFC 4975/4976 allows) broken. >> >>And, how is that different from an MSRP endpoint NOT=20 >>implementing the draft behind a MSRP-ALG? >=20 >MSRP would also be broken if two users not implementing the=20 >draft try to talk through a MSRP-ALG so, where is the=20 >problem? In the MSRP-ALG. >The draft would solve nothing in this case, neither it's=20 >guilty of the issue caused by the ALG but, So, the draft doesn't create that problem, nor does it claim to solve that = problem. >why should a RFC legitimize these ALG's and their wrong behaviour? I think we look at this from completely different angles :) You think that is legitimizes ALGs, while I think it raises the possibility= for MSRP communication to work in environments where ALGs are going to be = deployed anyway. You think it makes life easier for ALGs, while I think it makes life easier= for MSRP. >>>So IETF should product specifications taking into account vendors=20 >>>finances, is it? And what about the finances and resources of the=20 >>>implementors who have already implemented MSRP RFC 4975 and 4976 by=20 >>>respecting the OSI/Internet layers and the existing specifications? >> >> If their deployments work fine, they don't need to bother.=20 >> They will even work with sessmatch clients. >=20 >The difference is that they should be supposed to work in=20 >*any* correct and standarized scenario. But now with ALG's=20 >and this draft standarizing them, they will just work in same=20 >cases (when there is not an ALG). I don't think the draft "standardizes" ALGs, but I am the first to admit th= at the reason for the draft are ALGs. But, having said that, I don't think it really matters whether ALGs are "st= andardized" or not. They will be deployed if there is a requirement to depl= oy them. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 11:30:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCB4130086 for ; Wed, 25 May 2011 11:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8QIN5XwOM5i for ; Wed, 25 May 2011 11:30:39 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9C62213007B for ; Wed, 25 May 2011 11:30:38 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e1-4ddd4acded13 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 56.C6.20773.DCA4DDD4; Wed, 25 May 2011 20:30:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 20:30:36 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 25 May 2011 20:30:34 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbCE+32PIOKXB5QymlF3FxcnHuQgAASBog Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C807@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <4DDD4838.6090904@nostrum.com> In-Reply-To: <4DDD4838.6090904@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:30:39 -0000 Hi,=20 >>>I see no way a draft designed to optimize the network for=20 >>>behaviors that the IETF does not condone has any hope of passing IETF la= st=20 >>>call, much less the IESG. >>Is that a general comment, or you objecting to the draft=20 >>moving forward? >=20 >I've never stopped objecting to the draft moving forward. I guess I've missinterpreted the outcome of the off-line discussions in Pra= gue, then, when I thought we agreed on a way forward... Also, you did say that you saw fallback as a way forward. Or, did I missint= erpret that also? Regards, Christer From saul@ag-projects.com Wed May 25 11:31:14 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BA013007B for ; Wed, 25 May 2011 11:31:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mma4y+Rg08JE for ; Wed, 25 May 2011 11:31:13 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9413003D for ; Wed, 25 May 2011 11:31:13 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6F9C1B01C5; Wed, 25 May 2011 20:31:12 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B139EB0192; Wed, 25 May 2011 20:31:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 20:31:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:31:14 -0000 >>=20 >> An MSRP endpoint implementing this draft behind a MSRP-ALG=20 >> cannot talk with a MSRP endpoint not implementing it (RFC=20 >> 4975 broken), neither with a MSRP relay (RFC 4976 broken).=20 >> TLS name based authentication (as RFC 4975/4976 allows) broken. >=20 > And, how is that different from an MSRP endpoint NOT implementing the = draft behind a MSRP-ALG? >=20 You claim that scenario is broken, yet you stated no proof. Can you = please be explicit here? Lets assume Alice is NOT behind an ALG and Bob = is. The ALG does NOT do sessmatch. Alice calls Bob. How is this broken = and why in your opinion? -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 11:42:33 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D792113003D for ; Wed, 25 May 2011 11:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mehFXfpbfZsM for ; Wed, 25 May 2011 11:42:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6B013008C for ; Wed, 25 May 2011 11:42:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-72-4ddd4d97cf69 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.42.09774.79D4DDD4; Wed, 25 May 2011 20:42:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 20:42:31 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 20:42:26 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbCe3WLzjQplf5S3KeIfkQlyGJsQAAOWsA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:42:33 -0000 =20 >>> An MSRP endpoint implementing this draft behind a MSRP-ALG cannot=20 >>> talk with a MSRP endpoint not implementing it (RFC >>> 4975 broken), neither with a MSRP relay (RFC 4976 broken).=20 >>> TLS name based authentication (as RFC 4975/4976 allows) broken. >>=20 >> And, how is that different from an MSRP endpoint NOT=20 >> implementing the draft behind a MSRP-ALG? >>=20 >=20 >You claim that scenario is broken, yet you stated no proof.=20 >Can you please be explicit here? Lets assume Alice is NOT=20 >behind an ALG and Bob is. The ALG does NOT do sessmatch.=20 >Alice calls Bob. How is this broken and why in your opinion? It is broken if: - the media needs to be anchored (for whatever reason) by the ALG; and=20 - the ALG does is not a MSRP B2BUA. If the ALG is a MSRP B2BUA, there is no problem - which is also stated in t= he draft. Regards, Christer From ibc@aliax.net Wed May 25 11:43:13 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18CA713009C for ; Wed, 25 May 2011 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ik1t9iqgfhu for ; Wed, 25 May 2011 11:43:12 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5636813003D for ; Wed, 25 May 2011 11:43:12 -0700 (PDT) Received: by qyk29 with SMTP id 29so2722573qyk.10 for ; Wed, 25 May 2011 11:43:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr3274630qcb.285.1306348991574; Wed, 25 May 2011 11:43:11 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 11:43:11 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 20:43:11 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:43:13 -0000 2011/5/25 Christer Holmberg : > And, if you think that customers are so stupid that they are going to pay= for things they don't need, we for sure are not talking about the same cus= tomers... Sure, your clients are more important (I'm not joking). So, must IETF product a specification to satisfy your clients even if such specification is based on anything but what the IETF is supposed to promote (producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet)? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 11:47:44 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25973E0717 for ; Wed, 25 May 2011 11:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRbEqaWlvLf9 for ; Wed, 25 May 2011 11:47:43 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 81BDBE06A1 for ; Wed, 25 May 2011 11:47:43 -0700 (PDT) Received: by qyk7 with SMTP id 7so5436741qyk.10 for ; Wed, 25 May 2011 11:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4062257qcb.171.1306349262842; Wed, 25 May 2011 11:47:42 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 11:47:42 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 20:47:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:47:44 -0000 2011/5/25 Christer Holmberg : > It is broken if: > > - the media needs to be anchored (for whatever reason) by the ALG Dont' forget to add "without asking permission to the user". If the UA uses SIP over TLS the ALG has no way to anchor de media, should the ALG then reject such SIP TLS attemp? does it need to anchor the media or not? or "just" when it can? > - the ALG does is not a MSRP B2BUA. > > If the ALG is a MSRP B2BUA, there is no problem - which is also stated in= the draft. If the ALG is a MSRP B2BUA then it's not an ALG, so sessmatch is not needed at all, neither this draft. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 11:56:43 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8F3130076 for ; Wed, 25 May 2011 11:56:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kYNNN5t1Rn5 for ; Wed, 25 May 2011 11:56:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 557C0130011 for ; Wed, 25 May 2011 11:56:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-9d-4ddd50e929e3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.B4.09774.9E05DDD4; Wed, 25 May 2011 20:56:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 May 2011 20:56:41 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 20:56:40 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbC5qEIBG/s7VQR1iPywnrt6oJ+AAATzkw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C814@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 18:56:43 -0000 =20 >>And, if you think that customers are so stupid that they=20 >>are going to pay for things they don't need, we for sure are=20 >>not talking about the same customers... >=20 >Sure, your clients are more important (I'm not joking). I never said that. >So, must IETF product a specification to satisfy your clients=20 >even if such specification is based on anything but what the=20 >IETF is supposed to promote (producing high quality, relevant=20 >technical documents that influence the way people design,=20 >use, and manage the Internet)? We are not only satisfying my clients. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 12:01:35 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156961300A2 for ; Wed, 25 May 2011 12:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUsqgU+yhIgf for ; Wed, 25 May 2011 12:01:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 33496130090 for ; Wed, 25 May 2011 12:01:19 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-58-4ddd51fe5045 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DB.85.09774.EF15DDD4; Wed, 25 May 2011 21:01:18 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 21:01:17 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 25 May 2011 21:01:17 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbDDxSB2Yc92/TSL2xSaZhosgBGAAAU49g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C815@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:01:35 -0000 Hi,=20 >>It is broken if: >> >> - the media needs to be anchored (for whatever reason) by the ALG >=20 >Dont' forget to add "without asking permission to the user". Even if the user is asked for permission, if the ALG is not a MSRP B2BUA it= won't work. >If the UA uses SIP over TLS the ALG has no way to anchor de=20 >media, should the ALG then reject such SIP TLS attemp? does=20 >it need to anchor the media or not? or "just" when it can? What the ALG does in such cases is outside the scope of sessmatch - or even= MSRP. Regards, Christer From ben@estacado.net Wed May 25 12:53:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D1FE06A0 for ; Wed, 25 May 2011 12:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44vKWN-zkdvt for ; Wed, 25 May 2011 12:53:36 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 62222E0684 for ; Wed, 25 May 2011 12:53:35 -0700 (PDT) Received: from dn3-227.estacado.net (dn3-227.estacado.net [172.16.3.227]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p4PJrS9w044726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 May 2011 14:53:30 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <4DDBCA5D.5070104@nostrum.com> Date: Wed, 25 May 2011 14:53:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <537408AB-7130-47CA-A0DB-CC1F8E543408@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> <4DDBCA5D.5070104@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" , Simple WG Subject: [Simple] Concerns about option tag (was Re: WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments) X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 19:53:36 -0000 (as individual) On May 24, 2011, at 10:10 AM, Adam Roach wrote: > On 5/24/11 01:49, May 24, Christer Holmberg wrote: >> What about adding some text that STRONGLY RECOMMENDS entities to = implement a mechanism that allows fallback (e.g. switching to MSRP B2BUA = mode) to RFC4975 behavior in case the remote entity does not support = (or, isn't able to use due to a relay) sessmatch, rather than using the = Require header field? >=20 > So, to be clear, you're proposing that these intermediaries would not = insert a Require header field at all, and instead fall back to being an = MSRP B2BUA if the INVITE or its response doesn't indicate support? That = seems a reasonable path forward. >=20 On reflection, and even though I initially supported this as a good way = to resolve my concern about falling back to standard behavior, I have = some reservations about this approach. The surface issue is that we had, so far, said we weren't defining how = an intermediary (be it an ALG, SBC, or whatever) works. We can't really = place normative requirements on them unless we decide to go ahead and = specify at least part of their behavior. I'm not sure we want to take = that on in this working group. One potential way out would be to just = give guidance against the use of sessmatch in a Require header in an = INVITE, as well as the use of 421 responses. That would take away at = last part of the opportunity for intermediaries to force the use of = sessmatch (short of the current mechanism of just not working.) But the deeper issue is the question of what are we signaling with this = option tag in the first place. Negotiating the use of sessmatch doesn't = mean much for a UAC or a UAS. The draft says that without it, UAs must = fall back to RFC4975 matching rules--but it doesn't matter if they = don't. Anything that matches according to 4975 will also match according = to session match. It's the intermediaries that have to change behavior, = not the endpoints. So, in effect, we are using this option tag to signal = an extra-standard device that it can engage in behavior that is not = normatively specified anywhere. That seems to violate the spirit, if not = the letter, of the rule that an option tag must be specified in a = standards track RFC. This is more than a philosophical issue--it creates some practical = architectural issues. For example, if Alice supports sessmatch, but Bob = uses an MSRP relay, what happens? Can Bob simply not reflect the = sessmatch back in his response, and go ahead and use a relay? What if an = SBC had already munged the path header before Bob even saw Alice's = offer? Should Bob forgo the use of the relay, and just assume Alice's = SBC will fix everything? If so, then that gives Supported: sessmatch = almost the force of Require:sessmatch. I'm not sure we're on the right path here. An alternative might be to = signal sessmatch in the SDP, instead of in a SIP options tag. This would = avoid the issue of making a SIP only solution. But it would still = involve signaling a non-standardized device that it can invoke = non-standardized behavior. > /a > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From saul@ag-projects.com Wed May 25 13:10:49 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FF913009D for ; Wed, 25 May 2011 13:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBy9V9jd2Z3e for ; Wed, 25 May 2011 13:10:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 464AD130085 for ; Wed, 25 May 2011 13:10:49 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 6C80EB01C8; Wed, 25 May 2011 22:10:48 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id CE601B0192; Wed, 25 May 2011 22:10:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 22:10:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:10:49 -0000 >>=20 >> You claim that scenario is broken, yet you stated no proof.=20 >> Can you please be explicit here? Lets assume Alice is NOT=20 >> behind an ALG and Bob is. The ALG does NOT do sessmatch.=20 >> Alice calls Bob. How is this broken and why in your opinion? >=20 > It is broken if: >=20 > - the media needs to be anchored (for whatever reason) by the ALG; and=20= > - the ALG does is not a MSRP B2BUA. >=20 > If the ALG is a MSRP B2BUA, there is no problem - which is also stated = in the draft. >=20 I think you are mistaken here. If the media needs to be anchored the ALG = MUST be a B2BUA (if we don't consider this draft). There is no other way = to do it only with RFC4975 and 4976. This draft is only trying to help ALGs, not MSRP as a protocol. The = 'problem' that you are tying to solve was introduced by the ALG, if it = were a B2BUA there would be no problem at all. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 13:22:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4851300C5 for ; Wed, 25 May 2011 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.291 X-Spam-Level: X-Spam-Status: No, score=-6.291 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIzDflRwJhz1 for ; Wed, 25 May 2011 13:22:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id CF88B130085 for ; Wed, 25 May 2011 13:22:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-de-4ddd64eb06a9 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A5.63.09774.BE46DDD4; Wed, 25 May 2011 22:22:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 25 May 2011 22:22:03 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 22:22:00 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbF9cV3tABVisUSVuMebLW1NXzkAAAMb1Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:22:08 -0000 Hi,=20 >>>You claim that scenario is broken, yet you stated no proof.=20 >>>Can you please be explicit here? Lets assume Alice is NOT=20 >>>behind an ALG and Bob is. The ALG does NOT do sessmatch. >>>Alice calls Bob. How is this broken and why in your opinion? >>=20 >>It is broken if: >>=20 >>- the media needs to be anchored (for whatever reason) by=20 >>the ALG; and >>- the ALG does is not a MSRP B2BUA. >>=20 >>If the ALG is a MSRP B2BUA, there is no problem - which is=20 >>also stated in the draft. >>=20 >=20 >I think you are mistaken here. If the media needs to be=20 >anchored the ALG MUST be a B2BUA (if we don't consider this=20 >draft). There is no other way to do it only with RFC4975 and 4976. I agree. That's why I said that, unless the ALG is a MSRP B2BUA, things are broken. =20 >This draft is only trying to help ALGs, not MSRP as a=20 >protocol. Helping MSRP work easier with ALGs is also helping the protocol, in my opin= ion. >The 'problem' that you are tying to solve was introduced by the ALG, if it= were a B2BUA there would be no=20 >problem at all. I have not claimed otherwise. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 13:28:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E04D1300D7 for ; Wed, 25 May 2011 13:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.441 X-Spam-Level: X-Spam-Status: No, score=-7.441 tagged_above=-999 required=5 tests=[AWL=1.158, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQUdefzcmbdp for ; Wed, 25 May 2011 13:28:49 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB31300DB for ; Wed, 25 May 2011 13:28:48 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e7-4ddd667f2175 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 72.1B.20773.F766DDD4; Wed, 25 May 2011 22:28:47 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 25 May 2011 22:28:47 +0200 From: Christer Holmberg To: Ben Campbell , Adam Roach Date: Wed, 25 May 2011 22:28:43 +0200 Thread-Topic: Concerns about option tag (was Re: [Simple] WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments) - SDP instead of option-tag Thread-Index: AcwbFW5Ky7Xp5XnjRu2TW+s5xvNZPgAAPqGQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C838@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E2167A2@ESESSCMS0356.eemea.ericsson.se> <4DDBCA5D.5070104@nostrum.com> <537408AB-7130-47CA-A0DB-CC1F8E543408@estacado.net> In-Reply-To: <537408AB-7130-47CA-A0DB-CC1F8E543408@estacado.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 X-Brightmail-Tracker: AAAAAA== Cc: Simple WG , "draft-ietf-simple-msrp-sessmatch.all@tools.ietf.org" Subject: Re: [Simple] Concerns about option tag (was Re: WGLC Comments on draft-ietf-simple-sessmatch-11 - Ben's major comments) - SDP instead of option-tag X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:28:50 -0000 Hi Ben,=20 >>>What about adding some text that STRONGLY RECOMMENDS=20 >>>entities to implement a mechanism that allows fallback (e.g.=20 >>>switching to MSRP B2BUA mode) to RFC4975 behavior in case the=20 >>>remote entity does not support (or, isn't able to use due to=20 >>>a relay) sessmatch, rather than using the Require header field? >>=20 >>So, to be clear, you're proposing that these intermediaries=20 >>would not insert a Require header field at all, and instead=20 >>fall back to being an MSRP B2BUA if the INVITE or its=20 >>response doesn't indicate support? That seems a reasonable=20 >>path forward. > =20 >On reflection, and even though I initially supported this as=20 >a good way to resolve my concern about falling back to=20 >standard behavior, I have some reservations about this approach. Welcome to the club :) >The surface issue is that we had, so far, said we weren't=20 >defining how an intermediary (be it an ALG, SBC, or whatever)=20 >works. We can't really place normative requirements on them=20 >unless we decide to go ahead and specify at least part of=20 >their behavior. I'm not sure we want to take that on in this=20 >working group. > >One potential way out would be to just give guidance against the use of se= ssmatch=20 >in a Require header in an INVITE, as well as the use of 421 responses. Tha= t would=20 >take away at last part of the opportunity for intermediaries to force the = use of=20 >sessmatch (short of the current mechanism of just not working.) I have no problem to remove the Require part. (And, as discussed below, I have no problem to use SDP instead) >But the deeper issue is the question of what are we signaling=20 >with this option tag in the first place. Negotiating the use=20 >of sessmatch doesn't mean much for a UAC or a UAS. The draft=20 >says that without it, UAs must fall back to RFC4975 matching=20 >rules--but it doesn't matter if they don't. Anything that=20 >matches according to 4975 will also match according to=20 >session match. It's the intermediaries that have to change=20 >behavior, not the endpoints. So, in effect, we are using this=20 >option tag to signal an extra-standard device that it can=20 >engage in behavior that is not normatively specified=20 >anywhere. That seems to violate the spirit, if not the=20 >letter, of the rule that an option tag must be specified in a=20 >standards track RFC. > >This is more than a philosophical issue--it creates some=20 >practical architectural issues. For example, if Alice=20 >supports sessmatch, but Bob uses an MSRP relay, what happens?=20 >Can Bob simply not reflect the sessmatch back in his=20 >response, and go ahead and use a relay? >What if an SBC had already munged the path header before Bob even saw Alic= e's=20 >offer? Should Bob forgo the use of the relay, and just assume=20 >Alice's SBC will fix everything? If so, then that gives=20 >Supported: sessmatch almost the force of Require:sessmatch. I don't think Bob should be forced to forgo the relay. There are reasons=20 why Bob is using a relay (in the same way there are reasons others use=20 an ALG), and other entities should not be allowed to change that policy.=20 IF Bob does something, it's based on his own policies and decissions. Other= s=20 must not be able to force changes. >I'm not sure we're on the right path here. An alternative=20 >might be to signal sessmatch in the SDP, instead of in a SIP=20 >options tag. This would avoid the issue of making a SIP only=20 >solution. But it would still involve signaling a=20 >non-standardized device that it can invoke non-standardized behavior. I have no problem to use SDP instead. In the early phase of the work there = was an a=3Dmsrp-acm attribute, so I guess we could use something similar.=20 Regards, Christer From saul@ag-projects.com Wed May 25 13:30:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D731C1300DB for ; Wed, 25 May 2011 13:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8UyVJgcRn6r for ; Wed, 25 May 2011 13:30:34 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 482001300D7 for ; Wed, 25 May 2011 13:30:34 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id A6BBEB01C8; Wed, 25 May 2011 22:30:33 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2CCA1B00E6; Wed, 25 May 2011 22:30:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 22:30:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:30:35 -0000 Hi, >=20 >> The 'problem' that you are tying to solve was introduced by the ALG, = if it were a B2BUA there would be no=20 >> problem at all. >=20 > I have not claimed otherwise. >=20 If the problem was introduced by the ALG, then the ALG is what needs to = be fixed. Its as simple as that. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 13:38:40 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834FC1300DB for ; Wed, 25 May 2011 13:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz1kL6I8pYlT for ; Wed, 25 May 2011 13:38:40 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BF41B130085 for ; Wed, 25 May 2011 13:38:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-35-4ddd68ce3228 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.36.09774.EC86DDD4; Wed, 25 May 2011 22:38:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 22:38:36 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 22:38:35 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbGpmW2rcHwlRqS5eN0NsB6QsZlQAANDgg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:38:40 -0000 Hi,=20 >>> The 'problem' that you are tying to solve was introduced=20 >>> by the ALG, if it were a B2BUA there would be no problem at all. >>=20 >> I have not claimed otherwise. >>=20 >=20 >If the problem was introduced by the ALG, then the ALG is=20 >what needs to be fixed. Its as simple as that. Yes, in the same way NATs need to be fixed in order to solve the problems t= hey introduce... Regards, Christer= From saul@ag-projects.com Wed May 25 13:41:02 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D881300FB for ; Wed, 25 May 2011 13:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sa6zTOmoFT8 for ; Wed, 25 May 2011 13:41:01 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 796CF1300DB for ; Wed, 25 May 2011 13:41:01 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 787D4B01C9; Wed, 25 May 2011 22:41:00 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id F0026B00E6; Wed, 25 May 2011 22:40:59 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 22:40:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2A4041F2-5347-4C17-97CA-24075BAC81FF@ag-projects.com> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:41:02 -0000 >=20 > Yes, in the same way NATs need to be fixed in order to solve the = problems they introduce... >=20 One wrong does not justify another. -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Wed May 25 13:49:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6E1300EB for ; Wed, 25 May 2011 13:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmFP7pTOaWx7 for ; Wed, 25 May 2011 13:49:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 13AB41300EA for ; Wed, 25 May 2011 13:49:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-17-4ddd6b522480 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EE.2F.20773.25B6DDD4; Wed, 25 May 2011 22:49:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 22:49:22 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 22:49:21 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbHA8fxxIBaHLfSsuisI98/d3KGwAAF41w Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C843@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <2A4041F2-5347-4C17-97CA-24075BAC81FF@ag-projects.com> In-Reply-To: <2A4041F2-5347-4C17-97CA-24075BAC81FF@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:49:25 -0000 =20 >>Yes, in the same way NATs need to be fixed in order to=20 >>solve the problems they introduce... > =20 >One wrong does not justify another. Wrong or not, it's reality. Regards, Christer From ibc@aliax.net Wed May 25 13:50:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0951300EA for ; Wed, 25 May 2011 13:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWe1bJyS1mqg for ; Wed, 25 May 2011 13:50:27 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0E72AE0658 for ; Wed, 25 May 2011 13:50:23 -0700 (PDT) Received: by qyk7 with SMTP id 7so28907qyk.10 for ; Wed, 25 May 2011 13:50:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr7620qcb.247.1306356623354; Wed, 25 May 2011 13:50:23 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 13:50:23 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 22:50:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 20:50:28 -0000 2011/5/25 Christer Holmberg : > Yes, in the same way NATs need to be fixed in order to solve the problems= they introduce... NAT is a need (due to IPv4 limitation and the lack of IPv6 adoption). ALG's are not a need, not with currently available technology. NAT introduces problems, but without NAT things would be just impossible (no IPv4 for all the world). ALG's introduce problems, but without ALG's things can work (technology already provides solutions at application level). I don't think ALG should be compared with NAT. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Wed May 25 14:00:55 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3249D130074 for ; Wed, 25 May 2011 14:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-Oe7AjMvpKo for ; Wed, 25 May 2011 14:00:54 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7E6130073 for ; Wed, 25 May 2011 14:00:54 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 36DCEB01C8; Wed, 25 May 2011 23:00:52 +0200 (CEST) Received: from [192.168.1.122] (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id 0ABEBB00E6 for ; Wed, 25 May 2011 23:00:52 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Adrian Georgescu In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 23:00:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> To: "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:00:55 -0000 The arguments for continuing to pursue something completely broken by = design like sess-match are so far: 1. There were other worse things done in the past (like NATs) 2. There is a precedent with somebody having mentioned the word ALG in = a previous IETF document 3. The OMA made a reference about this draft By doing this draft we must all accept that: The fact that TLS does not work anymore does not matter The fact that it breaks compatibility with RFC 4975 and RFC 4976 does = not matter The fact that this can be implemented differently or poorly by = incompetent vendors with implications that go beyond what the authors = sees possible today does not matter The fact that SIP ALGs break communications does not matter, and a = similar model will become legitimate for MSRP protocol as well The fact that there is no know implementations that work today does not = matter The fact that existing MSRP implementations work well today and will = cease to work in the future as this draft becomes a standard does not = matter These should all be mentioned in the document before submitting it = further so that the reviewers can give a better judgement about whether = this should exist or not. I believe that what IETF stands for is in complete opposition with the = statements above. The SIMPLE WG should drop this draft and pass the problem to their = owner, OMA in this case. Adrian On May 25, 2011, at 10:38 PM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >>>> The 'problem' that you are tying to solve was introduced=20 >>>> by the ALG, if it were a B2BUA there would be no problem at all. >>>=20 >>> I have not claimed otherwise. >>>=20 >>=20 >> If the problem was introduced by the ALG, then the ALG is=20 >> what needs to be fixed. Its as simple as that. >=20 > Yes, in the same way NATs need to be fixed in order to solve the = problems they introduce... >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From ibc@aliax.net Wed May 25 14:01:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F113F13009F for ; Wed, 25 May 2011 14:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmllEx5j9jqR for ; Wed, 25 May 2011 14:01:07 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 48624130092 for ; Wed, 25 May 2011 14:01:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so2796210qyk.10 for ; Wed, 25 May 2011 14:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr26254qcb.171.1306357266618; Wed, 25 May 2011 14:01:06 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 14:01:06 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C843@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <2A4041F2-5347-4C17-97CA-24075BAC81FF@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C843@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 23:01:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:01:08 -0000 2011/5/25 Christer Holmberg : > Wrong or not, it's reality. Could you please explain who (names not needed, of course) is so interested in MSRP-ALG's and why it's a so big requirement for them? Also, could you please confirm me that those vendors don't want to deploy MRSP full B2BUA's and instead prefer promoting MSRP-ALG boxes (for example integrated within the IP/TCP routers)? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From adam@nostrum.com Wed May 25 14:16:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE2BE0724 for ; Wed, 25 May 2011 14:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs2tBg1amdQ2 for ; Wed, 25 May 2011 14:16:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 024B6E06A0 for ; Wed, 25 May 2011 14:16:11 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p4PLG84T044058 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 25 May 2011 16:16:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4DDD7198.2040702@nostrum.com> Date: Wed, 25 May 2011 16:16:08 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Christer Holmberg References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <4DDD4838.6090904@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C807@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C807@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:16:12 -0000 On 5/25/11 1:30 PM, Christer Holmberg wrote: >> I've never stopped objecting to the draft moving forward. > I guess I've missinterpreted the outcome of the off-line discussions in Prague, then, when I thought we agreed on a way forward... > > Also, you did say that you saw fallback as a way forward. Or, did I missinterpret that also? Since the inception of a draft that was explicitly incompatible with the existing MSRP architecture, I had two goals. The first is to stop it, preferably before we spend a lot of work on it. That's what I was trying to do in Dublin. The second is to work towards making it cause as little damage as possible, in case it does get published. The discussions in Prague, the comment about behavior fallback, and pretty much everything else I've said on the topic was an attempt to mitigate any damage that would be cause by publication. /a From ibc@aliax.net Wed May 25 14:25:08 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F445E0762 for ; Wed, 25 May 2011 14:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8bJwyvsUXpB for ; Wed, 25 May 2011 14:25:07 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 77109E075D for ; Wed, 25 May 2011 14:25:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so2807329qyk.10 for ; Wed, 25 May 2011 14:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr30007qcb.247.1306358706721; Wed, 25 May 2011 14:25:06 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 14:25:06 -0700 (PDT) In-Reply-To: <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> Date: Wed, 25 May 2011 23:25:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Adrian Georgescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:25:08 -0000 2011/5/25 Adrian Georgescu : > By doing this draft we must all accept that: Hi Adrian, just some comments: > The fact that it breaks compatibility with RFC 4975 and RFC 4976 does not= matter The author of the draft has already replied that your statement is false, as "in the absence of an MSRP-ALG, alice (implementing sessionmatch) and bob (not implementing it) can talk MSRP with no problem". But arguing that is useless as that is the case in which this draft does not take place at all. The fact is that when an ALG implementing this draft takes place, MSRP entities not implementing this draft (including MSRP relays) cannot talk with other entities behind the ALG box. And it's unacceptable that a RFC promotes something like this. > The fact that SIP ALGs break communications does not matter, and a simila= r model will become legitimate for MSRP protocol as well Even worse, as now vendors will have an IETF RFC specification justifying their aberration. It seems that the leasson learned after the proliferation of SIP-ALG routers does not apply here. BTW: is the reason learned? does people/vendors know about the big problems SIP-ALG routers have caused? Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 14:27:05 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A6FE0779 for ; Wed, 25 May 2011 14:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcVHWquyiD2e for ; Wed, 25 May 2011 14:27:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 51623E0762 for ; Wed, 25 May 2011 14:27:04 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ea-4ddd7427392e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.75.20773.7247DDD4; Wed, 25 May 2011 23:27:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 23:27:03 +0200 From: Christer Holmberg To: Adrian Georgescu , "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" Date: Wed, 25 May 2011 23:27:01 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbHt3c7E2kLgvrQ6G7QzGq1k1fkAAATZ5Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> In-Reply-To: <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:27:05 -0000 Hi,=20 >The arguments for continuing to pursue something completely=20 >broken by design like sess-match are so far: >=20 >1. There were other worse things done in the past (like NATs)=20 That is not an argument for continuing the work. >2. There is a precedent with somebody having mentioned the=20 >word ALG in a previous IETF document I am not aware of such argument. >3. The OMA made a reference about this draft That is ONE argument - and a very valid one, in my opinion. >By doing this draft we must all accept that: >=20 >The fact that TLS does not work anymore does not matter You can still use TLS. >The fact that it breaks compatibility with RFC 4975 and RFC 4976 does not = matter It does not break compability with RFC 4975 and RFC 4976. >The fact that this can be implemented differently or poorly by incompetent= vendors >with implications that go beyond what the authors sees possible today does= not matter If that were an argument I think we have to stop most of the IETF work... (One reason why people deploy ALGs is to fix things that have been poorly i= mplemented.) >The fact that SIP ALGs break communications does not matter, and a similar= model will=20 >become legitimate for MSRP protocol as well The fact that there is no know= implementations=20 >that work today does not matter I am not sure what kind of implementations you are talking about, but I can= inform you that there are working sessmatch implementations. >The fact that existing MSRP implementations work well=20 >today and will cease to work in the future as this draft=20 >becomes a standard does not matter I don't think implementation that works today will cease to work because of= sessmatch. >These should all be mentioned in the document before=20 >submitting it further so that the reviewers can give a better=20 >judgement about whether this should exist or not. I think I have addressed most issues (at least the ones people have agreed = upon) in the draft. >I believe that what IETF stands for is in complete opposition=20 >with the statements above. >=20 >The SIMPLE WG should drop this draft and pass the problem to=20 >their owner, OMA in this case. There are other owners too. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 14:29:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAFEE0762 for ; Wed, 25 May 2011 14:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X+UdRAlWMLS for ; Wed, 25 May 2011 14:29:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 01CF0E0730 for ; Wed, 25 May 2011 14:29:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-2f-4ddd74c87136 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D7.9F.09774.8C47DDD4; Wed, 25 May 2011 23:29:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 25 May 2011 23:29:44 +0200 From: Christer Holmberg To: Adam Roach Date: Wed, 25 May 2011 23:29:42 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbIQJIqoD9a2RIS6S3A4UivgECYgAAalmg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C851@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <4DDD4838.6090904@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C807@ESESSCMS0356.eemea.ericsson.se> <4DDD7198.2040702@nostrum.com> In-Reply-To: <4DDD7198.2040702@nostrum.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-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:29:47 -0000 =20 >>> I've never stopped objecting to the draft moving forward. >>> I guess I've missinterpreted the outcome of the off-line=20 >>> discussions in Prague, then, when I thought we agreed on a=20 >>> way forward... >> >>Also, you did say that you saw fallback as a way forward.=20 >>Or, did I missinterpret that also? >=20 >Since the inception of a draft that was explicitly=20 >incompatible with the existing MSRP architecture, I had two=20 >goals. The first is to stop it, preferably before we spend a=20 >lot of work on it. That's what I was trying to do in Dublin.=20 >The second is to work towards making it cause as little=20 >damage as possible, in case it does get published. The=20 >discussions in Prague, the comment about behavior fallback,=20 >and pretty much everything else I've said on the topic was an=20 >attempt to mitigate any damage that would be cause by publication. Thanks for the clarification. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 14:36:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D41E07DC for ; Wed, 25 May 2011 14:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-DlDvSHiS61 for ; Wed, 25 May 2011 14:36:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A7D9BE0762 for ; Wed, 25 May 2011 14:36:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1d-4ddd764a8663 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.D6.20773.A467DDD4; Wed, 25 May 2011 23:36:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 25 May 2011 23:36:10 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Adrian Georgescu Date: Wed, 25 May 2011 23:36:09 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbIjvbx1bng6clTZOQjoQO09zyQAAANJzA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C854@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:36:12 -0000 Hi,=20 >>The fact that it breaks compatibility with RFC 4975 and RFC 4976 does=20 >>not matter >=20 >The author of the draft has already replied that your=20 >statement is false, as "in the absence of an MSRP-ALG, alice=20 >(implementing sessionmatch) and bob (not implementing it) can talk MSRP=20 >with no problem". I couldn't have said it better myself :) >But arguing that is useless as that is the case in which this draft=20 >does not take place at all. >=20 >The fact is that when an ALG implementing this draft takes=20 >place, MSRP entities not implementing this draft (including=20 >MSRP relays) cannot talk with other entities behind the ALG=20 >box. And it's unacceptable that a RFC promotes something like this. Sessmatch promotes MSRP, by providing a mechanism that makes it easier to u= se in the presence of ALGs. I am not sure it's useful to have this philsophical discussions about what = promotes what, because we obviously have very different views, and it does = not help in solving the technical issues. >>The fact that SIP ALGs break communications does not matter, and a=20 >>similar model will become legitimate for MSRP protocol as well >=20 >Even worse, as now vendors will have an IETF RFC=20 >specification justifying their aberration. >=20 >It seems that the leasson learned after the proliferation of=20 >SIP-ALG routers does not apply here. BTW: is the reason=20 >learned? does people/vendors know about the big problems=20 >SIP-ALG routers have caused? Yes, and sessmatch is one outcome of those learnings :) Regards, Christer From saul@ag-projects.com Wed May 25 14:37:17 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291E0E07A5 for ; Wed, 25 May 2011 14:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UC+bsX+cR5b5 for ; Wed, 25 May 2011 14:37:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 52EBFE0762 for ; Wed, 25 May 2011 14:37:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9B5BAB01C9; Wed, 25 May 2011 23:37:15 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 07BB6B0192; Wed, 25 May 2011 23:37:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 23:37:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:37:17 -0000 Hi, >> The fact that it breaks compatibility with RFC 4975 and RFC 4976 does = not matter >=20 > It does not break compability with RFC 4975 and RFC 4976. >=20 It does. You don't seem to care about what I write, but I have explained = it several times already. It does break it. >=20 >> The fact that SIP ALGs break communications does not matter, and a = similar model will=20 >> become legitimate for MSRP protocol as well The fact that there is no = know implementations=20 >> that work today does not matter >=20 > I am not sure what kind of implementations you are talking about, but = I can inform you that there are working sessmatch implementations. >=20 Have you seen them working together with non-sessmatch implementations. = No. >> The fact that existing MSRP implementations work well=20 >> today and will cease to work in the future as this draft=20 >> becomes a standard does not matter >=20 > I don't think implementation that works today will cease to work = because of sessmatch. >=20 We implemented the whole stack and it will not work if we deal with = endpoints behind sessmatch enabled ALGs that don't do fallback. Again, the only way to avoid the damage this draft causes is to mandate = the fallback mechanism. -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed May 25 14:37:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA45E0783 for ; Wed, 25 May 2011 14:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkFMgA8UwmdP for ; Wed, 25 May 2011 14:37:33 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 96AEDE075B for ; Wed, 25 May 2011 14:37:33 -0700 (PDT) Received: by qyk29 with SMTP id 29so2813322qyk.10 for ; Wed, 25 May 2011 14:37:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr42188qci.209.1306359453025; Wed, 25 May 2011 14:37:33 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 14:37:32 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 23:37:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:37:34 -0000 2011/5/25 Christer Holmberg : >>By doing this draft we must all accept that: >> >>The fact that TLS does not work anymore does not matter > > You can still use TLS. ...without name based authentication. > (One reason why people deploy ALGs is to fix things that have been poorly= implemented.) Definitely we live in different worlds. >>The fact that existing MSRP implementations work well >>today and will cease to work in the future as this draft >>becomes a standard does not matter > > I don't think implementation that works today will cease to work because = of sessmatch. This has been explained 5-10 times today in different threads. Today's implementations (those with no sessionmatch) will just work with other today's implementations, but not with sessmatch aware MSRP entities in presence of MSRP-ALG's. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed May 25 14:49:58 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB0BE07C2 for ; Wed, 25 May 2011 14:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg65UMv4-+hN for ; Wed, 25 May 2011 14:49:57 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6924CE069D for ; Wed, 25 May 2011 14:49:57 -0700 (PDT) Received: by qwc23 with SMTP id 23so103713qwc.31 for ; Wed, 25 May 2011 14:49:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr49618qci.209.1306360196890; Wed, 25 May 2011 14:49:56 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 25 May 2011 14:49:56 -0700 (PDT) In-Reply-To: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 23:49:56 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:49:58 -0000 2011/5/25 Sa=C3=BAl Ibarra Corretg=C3=A9 : > Again, the only way to avoid the damage this draft causes is to mandate t= he fallback mechanism. Now let's laugh a bit: 1) Let's assume that vendors want to deploy MSRP-ALG boxes rather than MSRP relays or MSRP B2BUA's (all the stuff in a single box and so, cheaper, "simpler"...). 2) Let's assume that designing/building a MSRP-ALG router implementing sessmatch is easy (just apply some regular expression and replace a line in the SDP) and then brigde two TCP/TLS connections. 3) Let's assume that vendors capable of implementing point 2 are not always capable of building a full MSRP B2BUA (this cannot be done in 4 hours as point 2). And do we really expect that vendors will implement a "failover mechanism" which means building a full MSRP B2BUA (point 3) which is 2000 times more difficult than point 1 ??? (laughing...) This will not occur, neither if there is a MUST in the document. Take into account that most of the current vendors have decided to implement SIP-ALG in their routers (and there is no specification for it). --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed May 25 14:50:12 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E25E069D for ; Wed, 25 May 2011 14:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fO1e-+h4LukY for ; Wed, 25 May 2011 14:50:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 82609E0817 for ; Wed, 25 May 2011 14:50:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-17-4ddd7992a4c5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.13.09774.2997DDD4; Wed, 25 May 2011 23:50:10 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 25 May 2011 23:50:10 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 25 May 2011 23:50:08 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbI+sUoWo+OMePQcipD/q+cVQvEAAACZyA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C859@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:50:12 -0000 Hi,=20 >>>The fact that it breaks compatibility with RFC 4975 and RFC 4976 does no= t matter >>=20 >>It does not break compability with RFC 4975 and RFC 4976.=20 >=20 >It does. You don't seem to care about what I write, but I=20 >have explained it several times already. It does break it. I do care. But, I have explained as many times why I think it doesn't break= compability. But, since we obviously can't agree on that point, let's stop arguing about= it. >>> The fact that SIP ALGs break communications does not matter, and a=20 >>> similar model will become legitimate for MSRP protocol as well The=20 >>> fact that there is no know implementations that work today does not=20 >>> matter >>=20 >> I am not sure what kind of implementations you are talking=20 >> about, but I can inform you that there are working sessmatch=20 >> implementations. >>=20 >=20 >Have you seen them working together with non-sessmatch=20 >implementations. No. All I can say is that sessmatch works in cases where it is claimed to work. >>>The fact that existing MSRP implementations work well=20 >>>today and will cease to work in the future as this draft becomes a=20 >>>standard does not matter >>=20 >>I don't think implementation that works today will cease to=20 >>work because of sessmatch. >> =20 >We implemented the whole stack and it will not work if we=20 >deal with endpoints behind sessmatch enabled ALGs that don't=20 >do fallback. If you are talking about non-sessmatch endpoints it will not work behind no= n-sessmatch ALGs either. =20 >Again, the only way to avoid the damage this draft causes is=20 >to mandate the fallback mechanism. So, let's focus our discussions on that then, and skip the stuff that won't= take us anywhere. Regards, Christer From ag@ag-projects.com Wed May 25 14:51:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8446E0823 for ; Wed, 25 May 2011 14:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL4olIj4PB5m for ; Wed, 25 May 2011 14:51:57 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 27B38E081E for ; Wed, 25 May 2011 14:51:57 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8F0F2B01C2; Wed, 25 May 2011 23:51:56 +0200 (CEST) Received: from ag-air.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id E9949B0192 for ; Wed, 25 May 2011 23:51:55 +0200 (CEST) From: Adrian Georgescu Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--511882528 Date: Wed, 25 May 2011 23:51:55 +0200 In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> To: "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> Message-Id: X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 21:51:58 -0000 --Apple-Mail-1--511882528 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> By doing this draft we must all accept that: >>=20 >> The fact that TLS does not work anymore does not matter >=20 > You can still use TLS. You seem to be ignorant of what TLS is or does by saying this. Why would I want to use a TLS connection where the other end-point = cannot be verified? How could I ever exchange securely files and chat messages over an MSRP = connection using this draft? The protocol will become the laughing stock = of everyone. Would you do your banking transactions via an ALG that does insert = itself in the middle of your TLS session? IETF aims towards producing protocols with security properties not hacks = that break the most fundamental concepts of the Internet. sess-match is no match for this goal. --Apple-Mail-1--511882528 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
By doing = this draft we must all accept that:

The fact that = TLS does not work anymore does not matter

You can = still use TLS.

You = seem to be ignorant of what TLS is or does by saying = this.

Why would I want to use a TLS connection = where the other end-point cannot be = verified?

How could  I ever exchange = securely files and chat messages over an MSRP connection using this = draft? The protocol will become the laughing stock of = everyone.

Would you do your banking = transactions via an ALG that does insert itself in the middle of your = TLS session?

IETF aims towards producing = protocols with security properties not hacks that break the most = fundamental concepts of the = Internet.

sess-match is no match for this = goal.














<= div>


= --Apple-Mail-1--511882528-- From christer.holmberg@ericsson.com Wed May 25 15:00:45 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D21E06A3 for ; Wed, 25 May 2011 15:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRV6CW45YECI for ; Wed, 25 May 2011 15:00:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 25DD9E0680 for ; Wed, 25 May 2011 15:00:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-94-4ddd7c0ca47f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.D4.09774.C0C7DDD4; Thu, 26 May 2011 00:00:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 May 2011 00:00:44 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 26 May 2011 00:00:42 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbI/Vott9ihgA9RsyNp7sYzWcb2gAAi1jw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C85D@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:00:46 -0000 Hi,=20 >>>By doing this draft we must all accept that: >>> >>>The fact that TLS does not work anymore does not matter >> >> You can still use TLS. >=20 >...without name based authentication. If the ALG is a TLS B2BUA you can also use name based authentication. But, if the ALG relays the TLS connection, I agree. =20 >>>The fact that existing MSRP implementations work well today=20 >>>and will cease to work in the future as this draft becomes a=20 >>>standard does not matter >> >>I don't think implementation that works today will cease to=20 >>work because of sessmatch. >=20 >This has been explained 5-10 times today in different=20 >threads. Today's implementations (those with no sessionmatch)=20 >will just work with other today's implementations, but not=20 >with sessmatch aware MSRP entities in presence of MSRP-ALG's. ...and not with any other today's MSRP entities either. I suggest that we stop to argue about this now. We DO see to agree on which= scenarios will work, and which won't. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 15:09:19 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395EFE0762 for ; Wed, 25 May 2011 15:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StmNJZHJlHcP for ; Wed, 25 May 2011 15:09:18 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 619A3E0730 for ; Wed, 25 May 2011 15:09:18 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c4-4ddd7e0db887 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4D.9C.20773.D0E7DDD4; Thu, 26 May 2011 00:09:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 May 2011 00:09:17 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Thu, 26 May 2011 00:09:15 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbJbFVQXuH6b86SEaRz5UTzu4q+AAAbELw Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C85F@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adrian Georgescu , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:09:19 -0000 Hi,=20 >>Again, the only way to avoid the damage this draft causes=20 >>is to mandate the fallback mechanism. >=20 >Now let's laugh a bit: I stopped laughing many e-mails ago :) >1) Let's assume that vendors want to deploy MSRP-ALG boxes=20 >rather than MSRP relays or MSRP B2BUA's (all the stuff in a=20 >single box and so, cheaper, "simpler"...). >=20 >2) Let's assume that designing/building a MSRP-ALG router=20 >implementing sessmatch is easy (just apply some regular=20 >expression and replace a line in the SDP) and then brigde two=20 >TCP/TLS connections. >=20 >3) Let's assume that vendors capable of implementing point 2=20 >are not always capable of building a full MSRP B2BUA (this=20 >cannot be done in 4 hours as point 2). > >And do we really expect that vendors will implement a=20 >"failover mechanism" which means building a full MSRP B2BUA=20 >(point 3) which is 2000 times more difficult than point 1 ???=20 >(laughing...) > >This will not occur, neither if there is a MUST in the=20 >document. Take into account that most of the current vendors=20 >have decided to implement SIP-ALG in their routers (and there=20 >is no specification for it). That applies to any MUST in any document. There is nothing we can do about = that. All WE can do is justify and describe the importance of implementing the MU= STs. Customer requirements will in the end always decide what is implemented. Regards, Christer From christer.holmberg@ericsson.com Wed May 25 15:15:39 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED57E0776 for ; Wed, 25 May 2011 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQRiiEogm26y for ; Wed, 25 May 2011 15:15:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id AE80EE0739 for ; Wed, 25 May 2011 15:15:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d3-4ddd7f89a6fc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 19.27.09774.98F7DDD4; Thu, 26 May 2011 00:15:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 May 2011 00:15:37 +0200 From: Christer Holmberg To: Adrian Georgescu , "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" Date: Thu, 26 May 2011 00:15:36 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbJftlNYA/CAKZTeCCfLp7mM6QhQAAq8rQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C861@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7FD@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C80F@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C837@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E25C83B@ESESSCMS0356.eemea.ericsson.se> <5EA56FBB-46F4-4B21-B31C-34600D3FB88B@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C84E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 22:15:39 -0000 Hi,=20 =09 >You seem to be ignorant of what TLS is or does by saying this. > >Why would I want to use a TLS connection where the other end-point cannot = be verified? The draft does talk about a case where you have an end-to-end MSRP TLS conn= ection. Regards, Christer >How could I ever exchange securely files and chat messages over an MSRP c= onnection=20 >using this draft? The protocol will become the laughing stock of everyone. > >Would you do your banking transactions via an ALG that does insert itself = in the middle of your TLS session? > >IETF aims towards producing protocols with security properties not hacks t= hat break the most fundamental concepts of the Internet. > >sess-match is no match for this goal. From fluffy@cisco.com Wed May 25 18:53:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00FE06A3 for ; Wed, 25 May 2011 18:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.468 X-Spam-Level: X-Spam-Status: No, score=-110.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq1aRY1KXD9Z for ; Wed, 25 May 2011 18:53:24 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 069A5E0671 for ; Wed, 25 May 2011 18:53:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1696; q=dns/txt; s=iport; t=1306374804; x=1307584404; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=12ej6uSO45A3ecjpS/s5wR2GDzsObQaDo7u8ny1a0YE=; b=Pbp/YhmUQEkqw22OxJzMoli7C9gfjpnaHVBi33ztgOEKzF4edxvByxkm YQ2Zc6SHWDP8lteA7jgrMdbyDEu3ujPRr7dwLLG167ksf2HHI6Mer31Hi gna8+2CD+rBUr8r8/R67kbPI3U1qDIfR+LhsI1Vc4jJJ2z5PTqyjiFj+W o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+x3U2rRDoH/2dsb2JhbACmOniIcJ9rnVmGHASGXIlYhDmKcg X-IronPort-AV: E=Sophos;i="4.65,270,1304294400"; d="scan'208";a="364431127" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-2.cisco.com with ESMTP; 26 May 2011 01:53:23 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4Q1rMBJ023966; Thu, 26 May 2011 01:53:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 19:53:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1871898F-7939-49C3-84D1-E00A2A5968A1@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3CD@ESESSCMS0356.eemea.ericsson.se> <11B3F21D-453A-4544-A1F2-C2D9EE6C09F0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3D0@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C865@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C867@ESESSCMS0356.eemea.ericsson.se> <5CA2ECFB-D216-46F7-A876-7B7D86E6270E@ag-projects.com> <78E00745-B30D-4363-9803-4AA2E0D59F86@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C869@ESESSCMS0356.eemea.ericsson.se> <4A502246-72E6-4DFB-92A0-C8105535CA9C@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585 194DF6C870@ESESSCMS0356.eemea.ericsson.se> <025C82B4-2E10-4849-9C8F-6014FFDAF5A5@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C872@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6C874@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "DRAGE, Keith \(Keith\)" , Adrian Georgescu , Simple WG Subject: Re: [Simple] About draft-ietf-simple-sessmatch X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 01:53:24 -0000 On May 25, 2011, at 7:28 AM, Christer Holmberg wrote: >=20 > I think IETF SIMPLE WG should make specifications that can work in = real-life networks. They do. The NAT issue was one of the arguments for relays in MSRP in = the first place. The IETF advice on ALG is in=20 BCP 127 REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define ALGs can update this to recommend the defaults for the ALGs that they define. and from BCP 142 is=20 REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP]) be disabled by default. The reasons why is basically protocols are not designed to work with = random intermediaries changing bits. Protocols are designed for = intermediaries that go by names such as relays, proxies, and B2BUA in = the sip context. These are components of the system specifically = designed such that they work - more importunity future extensions to the = protocol are designed not to break them.=20 Now I realize there are SIP ALGs out there - but they don't work very = well. One of the biggest problems they have is adapting to future = changes of the protocol. I'm pretty shocked to see any other SDO base = an architecture on something as vaguely defined as the term ALG. But = what other SDOs do is their concern not mind. Many of the real world = scenarios I care about run SIP over TLS or DTLS (via the AnyConnnect VPN = stuff) so that ALGs don't break things.=20 From fluffy@cisco.com Wed May 25 18:54:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F339E06A3 for ; Wed, 25 May 2011 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.182 X-Spam-Level: X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpT7XG1USrn3 for ; Wed, 25 May 2011 18:54:06 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id D8AF5E0671 for ; Wed, 25 May 2011 18:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=4830; q=dns/txt; s=iport; t=1306374846; x=1307584446; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NfX7xdymLTa7LenUhP+6ROi92JBEOlAw174XDN0EXNU=; b=iRuRgg0a6CI6JPCgugku3B0n2TbNZfiqIF8cPF5Zdes2hpOQ29kqpZ6X PkZAXVUhO46ANhYgCYBn37A7E4lCjvT9hJXpbhYxbHs/X05ffSlk7a5PX zoL6TFKFDcZM76SUFbfu0pDOXOaN3kKe1XmEi9S/wsi7f29c2E7+3Zj5I w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+x3U2rRDoH/2dsb2JhbACmOniIcJ9rnVmGHASGXIlYhDmKcg X-IronPort-AV: E=Sophos;i="4.65,270,1304294400"; d="scan'208";a="703505670" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 26 May 2011 01:54:06 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p4Q1rMBK023966; Thu, 26 May 2011 01:54:05 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <54A780CB-4E3A-4B9B-95D3-14517FD45E0C@ag-projects.com> Date: Wed, 25 May 2011 19:54:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8369904E-32D4-4E7B-9004-4E5E7EAA12C1@cisco.com> References: <4DDCE1DF.2050901@ericsson.com> <54A780CB-4E3A-4B9B-95D3-14517FD45E0C@ag-projects.com> To: Adrian Georgescu X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "simple-chairs@tools.ietf.org Chairs" , Simple WG Subject: [Simple] Sugestion one way forward Re: WGLC of draft-ietf-simple-msrp-sessmatch-11 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 01:54:07 -0000 Most IETF specs are held to the standard of being usable on the = internet. I'm trying to figure out a pragmatic way forward. In other = cases like this we have sometimes published an historic RFC with a title = along the lines of "OMA's Session Matching Optimization for MSRP" and = clearly outline that is applicable for networks where all clients are = known to implement it.=20 One thing I don't think we should do is publish a spec that breaks = backwards compatibility with existing MSRP clients. I know Christer has = worked hard to try and make there be a reasonable fallback mechanisms = and I am please to hear that some vendors would implement it. I think = the key thing is look at the trade off of how much performance gain this = optimization provides vs the breakage it can cause when used outside the = context of a 3GPP or OMA environment. I think it is pretty clear that = most ALGs will not fall back to B2BUA mode. If they had the code to do = that they would act as B2BUA based SBC in the first place and never even = bother with all the nightmares of being an ALG.=20 =20 On May 25, 2011, at 7:11 AM, Adrian Georgescu wrote: > Hi Gonzallo, >=20 > I am wondering. If the only applicability of sess-match is for = deploying a service behind an OMA style walled garden, why does it have = to be an IETF document about it? It can be an OMA or 3GPP = specification, that is fine. Is architecture in the end, how to use (or = miss-use) existing protocols for achieving some purpose, not a protocol = specification. >=20 > Why an IETF one that explicitly breaks what has already been created = so far? Creating a standard for how to insert intermediaries in a = working protocol? Leaving a door open for all possible problems that = will emerge out of this? >=20 > This is not rhetorical, I just try to understand why a = non-interoperable standard with execrable security and integrity = properties which has nothing to do with public Internet is developed = within the IETF? Isn't it possible to just pass the ball away to where = it belongs? OMA, 3GPP or other organization that cares about it. >=20 > Adrian >=20 > On May 25, 2011, at 1:02 PM, Gonzalo Camarillo wrote: >=20 >> Hi, >>=20 >> given that the backwards compatibility properties of this extension = have >> caused some concern, the draft needs to do a better job describing = them. >> Being explicit about them is important. The last paragraph of Section = 1 >> should be edited so that it captures the different scenarios that = have >> been discussed on this list. The authors may even consider having a >> brief section about backwards compatibility, which would also include >> the comments about having to implement regular MRSP procedures as the >> fall-back mechanism at a MUST or a SHOULD level (whatever the WG = decides). >>=20 >> Also, within that paragraph, the following sentence is confusing: >>=20 >>> MSRP entities that do not implement the sessmatch extension, and >>> communicate with ALGs that do not implement MSRP B2BUA = functionality, >>> can normally not establish MSRP sessions, since the session = matching >>> will fail in case the address information of the SDP a=3Dpath = attribute >>> has been modified by the ALGs. >>=20 >> That is not a standard scenario because before this extension was >> defined, ALGs needed to implement MSRP B2BUA functionality. The draft >> can say that this extension enables that scenario, but the draft = should >> not talk about non-standard behavior in the context of backwards >> compatibility because things can get quite confusing. >>=20 >> Thanks, >>=20 >> Gonzalo >>=20 >>=20 >>=20 >> On 23/05/2011 6:51 PM, Ben Campbell wrote: >>> This is a Working Group Last Call of = draft-ietf-simple-msrp-sessmatch-11: >>>=20 >>> http://tools.ietf.org/html/draft-ietf-simple-msrp-sessmatch-11 >>>=20 >>> Please note that this draft contains substantial new text since = version 10, primarily concerning the use of an option tag. Even if you = were happy with version 10, please review this version. >>>=20 >>> The WGLC will conclude on 6 June 2011. Please send your comments, = including nits and "this is ready to go" type comments, to the authors = and the working group list. >>>=20 >>> Thanks! >>>=20 >>> Ben.=20 >>> _______________________________________________ >>> Simple mailing list >>> Simple@ietf.org >>> https://www.ietf.org/mailman/listinfo/simple >>>=20 >>=20 >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From fluffy@cisco.com Wed May 25 19:09:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39DBE06A3 for ; Wed, 25 May 2011 19:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsc06wCr31k5 for ; Wed, 25 May 2011 19:09:36 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFCCE066C for ; Wed, 25 May 2011 19:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1229; q=dns/txt; s=iport; t=1306375776; x=1307585376; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Mq/+V+G0jQXfjAtBzVYnvKFSSBfI+SNqqwn+JqNLzzs=; b=ecICIVThcbrOu7YLkHhwFOGpjLb1qJzbWRmoC+D6EBLN8T9S9d581lk7 wQzpmW5ognmWEpPN4tpHd2KIP06n4oOxpRcJHMh+eCnecXwoUJFCi7cCh deahgG8NeprA7I0obkJlP1ZTUtwqkld+qLcS2pqJ7KVjeQ9m/gfIX64IX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACa13U2rRDoI/2dsb2JhbACmOniIcJ9rnVqGHASGXIlYhDmKcg X-IronPort-AV: E=Sophos;i="4.65,270,1304294400"; d="scan'208";a="454476010" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 26 May 2011 02:09:35 +0000 Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p4Q29YSd022283; Thu, 26 May 2011 02:09:35 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 25 May 2011 20:09:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 02:09:36 -0000 On May 25, 2011, at 10:47 AM, Christer Holmberg wrote: >> I see no way a draft designed to optimize the network for=20 >> behaviors that the IETF does not condone has any hope of=20 >> passing IETF last call, much less the IESG. >=20 > Is that a general comment, or you objecting to the draft moving = forward? Just as a summary of where I see things ... you have some people that = want to use this draft more or less as is. They feel it will meet the = needs of an OMA like deployment. You also have some people that are not = convinced that this does not have backwards compatible problems or = security problems when used on the internet. The exact details of this = are complex enough that it is not easy for most the people who have = commented on this draft at one point or another to even decide if there = agree there are problems or not. The list of people that believe there = are problems are not some random casual bystanders - some of them have = deep understanding of the protocol and includes people who implemented = MSRP and some of the authors.=20 Pretty hard to claim you have consensus in a situation like that. People = are worn down by this conversation and just giving up.=20= From md3135@att.com Wed May 25 19:23:51 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB2FBE06F4 for ; Wed, 25 May 2011 19:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bX0BytS3kGg for ; Wed, 25 May 2011 19:23:51 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 65B4CE06A3 for ; Wed, 25 May 2011 19:23:51 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-14.tower-120.messagelabs.com!1306376629!19494056!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 17570 invoked from network); 26 May 2011 02:23:50 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-14.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 May 2011 02:23:50 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4Q2Mieu013231 for ; Wed, 25 May 2011 22:22:44 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p4Q2MhIY013223 for ; Wed, 25 May 2011 22:22:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 May 2011 22:23:47 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A22D024@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbSfwFKlarQaJQR9OjVUhDSeRgJwAAJHkg References: <4DDD2D67.3000708@nostrum.com><7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> From: "DOLLY, MARTIN C (ATTSI)" To: "Cullen Jennings" , "Christer Holmberg" Cc: "DALY, BRIAN K \(ATTSI\)" , Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 02:23:52 -0000 Cullen, Carriers, at least AT&T, supports the points that Christer has been making in this marathon email thread today. Simply put, your open internet points, do not meet industry needs. This sounds like an issue for 3GPP/IETF coordination. Regards, Martin Dolly Lead Member Technical Staff Core & Government/Regulatory Standards AT&T Services, Inc. md3135@att.com +1-609-903-3360 -----Original Message----- From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, May 25, 2011 10:10 PM To: Christer Holmberg Cc: Adam Roach; SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG Subject: Re: [Simple] sessmatch: to be or not to be? On May 25, 2011, at 10:47 AM, Christer Holmberg wrote: >> I see no way a draft designed to optimize the network for=20 >> behaviors that the IETF does not condone has any hope of=20 >> passing IETF last call, much less the IESG. >=20 > Is that a general comment, or you objecting to the draft moving forward? Just as a summary of where I see things ... you have some people that want to use this draft more or less as is. They feel it will meet the needs of an OMA like deployment. You also have some people that are not convinced that this does not have backwards compatible problems or security problems when used on the internet. The exact details of this are complex enough that it is not easy for most the people who have commented on this draft at one point or another to even decide if there agree there are problems or not. The list of people that believe there are problems are not some random casual bystanders - some of them have deep understanding of the protocol and includes people who implemented MSRP and some of the authors.=20 Pretty hard to claim you have consensus in a situation like that. People are worn down by this conversation and just giving up.=20 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Wed May 25 23:50:24 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFA8E0706 for ; Wed, 25 May 2011 23:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af3VKUGvkodR for ; Wed, 25 May 2011 23:50:23 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 245A9E0731 for ; Wed, 25 May 2011 23:50:22 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-6a-4dddf82dbbc1 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B7.27.09774.D28FDDD4; Thu, 26 May 2011 08:50:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 26 May 2011 08:50:17 +0200 From: Christer Holmberg To: Cullen Jennings Date: Thu, 26 May 2011 08:50:16 +0200 Thread-Topic: [Simple] sessmatch: to be or not to be? Thread-Index: AcwbSfewyJADzjvuRf2HDK00Lrd/sQAI+ZZg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25C8EC@ESESSCMS0356.eemea.ericsson.se> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: 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-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 06:50:24 -0000 Hi Cullen,=20 >The list of people that believe there are problems are not some random=20 >casual bystanders - some of them have deep understanding of=20 >the protocol and includes people who implemented MSRP and=20 >some of the authors.=20 I have great respect for those people (please let me know if I have ever cl= aimed anything else). That is why I have spent lots of time, also involving= my own security experts and implementors, trying to understand and address= the comments and issues given by them. I am also extremely thankful that m= ost of those people also spend much of their own on this, by replying back = fast etc. Regards, Christer = From ibc@aliax.net Thu May 26 00:50:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29EEAE065B for ; Thu, 26 May 2011 00:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmMLOAd9u4Ja for ; Thu, 26 May 2011 00:50:30 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 19BE9E0671 for ; Thu, 26 May 2011 00:50:29 -0700 (PDT) Received: by qyk7 with SMTP id 7so256095qyk.10 for ; Thu, 26 May 2011 00:50:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr323664qcb.247.1306396225995; Thu, 26 May 2011 00:50:25 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Thu, 26 May 2011 00:50:25 -0700 (PDT) In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A22D024@gaalpa1msgusr7e.ugd.att.com> References: <4DDD2D67.3000708@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <14C85D6CCBE92743AF33663BF5D24EBA0A22D024@gaalpa1msgusr7e.ugd.att.com> Date: Thu, 26 May 2011 09:50:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "DOLLY, MARTIN C (ATTSI)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , "DALY, BRIAN K \(ATTSI\)" , Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 07:50:31 -0000 2011/5/26 DOLLY, MARTIN C (ATTSI) : > Carriers, at least AT&T, supports the points that Christer has been > making in this marathon email thread today. Finally I know who "the customers" are, and they seem important :) > Simply put, your open internet points, do not meet industry needs. IETF is supposed to worry about Internet ("The goal of the IETF is to make the Internet work better") rather than satisfy the industry by breaking basic OSI/Internet layers and already working protocolos just in favour of the some very big vendors, no matter how big they are. This specifications breaks things (working things) in favour of an "anomaly" (SIP ALG's) just because some vendors don't want to adopt the solutions already standarized by the IETF (i.e. MSRP relays). This specifications helps ALG boxes intercepting users's traffic without their consent. This specification is against the basic principles IETF publications are supposed to promote. If this was a famous movie, who would be "the Bad"? > This sounds like an issue for 3GPP/IETF coordination. IMHO the specification discussed here makes no sense in IETF, maybe that is the issue (just my opinion). Regards. --=20 I=C3=B1aki Baz Castillo From ag@ag-projects.com Thu May 26 01:03:20 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC0CE0706 for ; Thu, 26 May 2011 01:03:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqHHLo-KHXWv for ; Thu, 26 May 2011 01:03:19 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A2235E0670 for ; Thu, 26 May 2011 01:03:17 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 150C1B01C9; Thu, 26 May 2011 10:03:15 +0200 (CEST) Received: from imac3.fritz.box (mit.xs4all.nl [80.101.96.20]) by mail.sipthor.net (Postfix) with ESMTPSA id CB58CB00E6; Thu, 26 May 2011 10:03:11 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Adrian Georgescu In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A22D024@gaalpa1msgusr7e.ugd.att.com> Date: Thu, 26 May 2011 10:03:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <182626C5-AE85-4F1C-9AEF-AF3363E48672@ag-projects.com> References: <4DDD2D67.3000708@nostrum.com><7F2072F1E0DE894DA4B517B93C6A0585194E25C7E2@ESESSCMS0356.eemea.ericsson.se> <14C85D6CCBE92743AF33663BF5D24EBA0A22D024@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , "DALY, BRIAN K \(ATTSI\)" , Adam Roach , "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] sessmatch: to be or not to be? X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 08:03:20 -0000 Hello Martin, I do not believe that being AT& T entitles you to help create an IETF = standard that breaks every other MSRP deployment on the Internet. What you ask for is agains the Internet principles and hurts a lot of = people and their investment so far in an Internet protocol that works = just fine today and will not anymore once this document is adopted. sess-match does not belong to IETF, it may belongs to RFPs for your = suppliers that build your wall garden, nobody else needs such = specification except you and your vendors. This specifications has nothing to do with improving the Internet but = the opposite, by breaking it. Adrian On May 26, 2011, at 4:23 AM, DOLLY, MARTIN C (ATTSI) wrote: > Cullen, >=20 > Carriers, at least AT&T, supports the points that Christer has been > making in this marathon email thread today. >=20 > Simply put, your open internet points, do not meet industry needs. >=20 > This sounds like an issue for 3GPP/IETF coordination. >=20 > Regards, >=20 > Martin Dolly > Lead Member Technical Staff > Core & Government/Regulatory Standards > AT&T Services, Inc. > md3135@att.com > +1-609-903-3360 >=20 >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf > Of Cullen Jennings > Sent: Wednesday, May 25, 2011 10:10 PM > To: Christer Holmberg > Cc: Adam Roach; SIMPLE (SIP for Instant Messaging and Presence > Leveraging Extensions) WG > Subject: Re: [Simple] sessmatch: to be or not to be? >=20 >=20 > On May 25, 2011, at 10:47 AM, Christer Holmberg wrote: >=20 >>> I see no way a draft designed to optimize the network for=20 >>> behaviors that the IETF does not condone has any hope of=20 >>> passing IETF last call, much less the IESG. >>=20 >> Is that a general comment, or you objecting to the draft moving > forward? >=20 > Just as a summary of where I see things ... you have some people that > want to use this draft more or less as is. They feel it will meet the > needs of an OMA like deployment. You also have some people that are = not > convinced that this does not have backwards compatible problems or > security problems when used on the internet. The exact details of this > are complex enough that it is not easy for most the people who have > commented on this draft at one point or another to even decide if = there > agree there are problems or not. The list of people that believe there > are problems are not some random casual bystanders - some of them have > deep understanding of the protocol and includes people who implemented > MSRP and some of the authors.=20 >=20 > Pretty hard to claim you have consensus in a situation like that. = People > are worn down by this conversation and just giving up.=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple >=20 From christer.holmberg@ericsson.com Thu May 26 02:46:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF90E06D5 for ; Thu, 26 May 2011 02:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FSM6CO0o223g for ; Thu, 26 May 2011 02:46:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 61FF8E06D1 for ; Thu, 26 May 2011 02:46:56 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-ad-4dde218e2ccf Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.82.20773.E812EDD4; Thu, 26 May 2011 11:46:55 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 May 2011 11:46:54 +0200 From: Christer Holmberg To: "SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) WG" Date: Thu, 26 May 2011 11:46:52 +0200 Thread-Topic: Sessmatch products Thread-Index: AQHMG4a20VLgN3yIUkaKOBtV3TgN+A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:46:57 -0000 Hi, There has been comments about the existence of sessmatch products, so let m= e give some information from my own company. The Ericsson's carrier class SBC currently supports running in either sessm= atch mode or TCP/MSRP B2BUA mode, and we currently see no problem in implem= enting fallback.=20 In sessmatch mode the troughput for MSRP packets is line-interface wirespee= d, while in MSRP B2BUA mode the maximum throughput for MSRP packets is much= lower. One application we are using MSRP for is to transfer video clips between us= er endpoints, and we would like to have the option of not having to use B2B= UA mode if it can be avoided.=20 So, the main issue (at least not from our perspective) is not the code it t= akes to implement TCP/MSRP B2BUA functionaltiy, but the performance impacts= when one has to use it. Regards, Christer= From saul@ag-projects.com Thu May 26 02:53:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0BCE06D5 for ; Thu, 26 May 2011 02:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9XqpvqfWB9U for ; Thu, 26 May 2011 02:53:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4C5E06D1 for ; Thu, 26 May 2011 02:53:30 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 78460B01B5; Thu, 26 May 2011 11:53:29 +0200 (CEST) Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D860CB0192; Thu, 26 May 2011 11:53:28 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 26 May 2011 11:53:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 09:53:31 -0000 Hi, On May 26, 2011, at 11:46 AM, Christer Holmberg wrote: > Hi, >=20 > There has been comments about the existence of sessmatch products, so = let me give some information from my own company. >=20 Cool, real stuff :-) > The Ericsson's carrier class SBC currently supports running in either = sessmatch mode or TCP/MSRP B2BUA mode, and we currently see no problem = in implementing fallback.=20 >=20 > In sessmatch mode the troughput for MSRP packets is line-interface = wirespeed, while in MSRP B2BUA mode the maximum throughput for MSRP = packets is much lower. >=20 > One application we are using MSRP for is to transfer video clips = between user endpoints, and we would like to have the option of not = having to use B2BUA mode if it can be avoided.=20 >=20 > So, the main issue (at least not from our perspective) is not the code = it takes to implement TCP/MSRP B2BUA functionaltiy, but the performance = impacts when one has to use it. >=20 I understand. What about this: since your endpoints support sessmatch, = the cheapest approach would be used by your ALG and the performance = would be just fine. And if another endpoint that does not support = sessmatch connects to your ALG the B2BUA mode would be used. Would that be reasonable for vendors? They can implement sessmatch on = the endpoints but keeping the B2BUA mode for those who don't. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Thu May 26 03:31:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D704E06D5 for ; Thu, 26 May 2011 03:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3B-GRK45zas for ; Thu, 26 May 2011 03:31:21 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 03D56E068F for ; Thu, 26 May 2011 03:31:20 -0700 (PDT) Received: by qyk29 with SMTP id 29so3092825qyk.10 for ; Thu, 26 May 2011 03:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr423192qci.209.1306405880205; Thu, 26 May 2011 03:31:20 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Thu, 26 May 2011 03:31:20 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> Date: Thu, 26 May 2011 12:31:20 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:31:21 -0000 2011/5/26 Christer Holmberg : > So, the main issue (at least not from our perspective) is not the code it= takes to implement TCP/MSRP B2BUA functionaltiy, but the performance impac= ts when one has to use it. I wonder whether small manufactures of routers (those which include painful SIP-ALG enabled by default) will be also capable of building such fallback mechanism (MSRP B2BUA). --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu May 26 03:39:23 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DDC5E0679 for ; Thu, 26 May 2011 03:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAA9Pz1mKecN for ; Thu, 26 May 2011 03:39:22 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2338FE0664 for ; Thu, 26 May 2011 03:39:21 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d9-4dde2dd809c0 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 73.42.09774.8DD2EDD4; Thu, 26 May 2011 12:39:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 26 May 2011 12:39:20 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 26 May 2011 12:39:18 +0200 Thread-Topic: [Simple] Sessmatch products Thread-Index: AcwbkA5xEZgxR1f5Qa+nDk4qK+AZSgAAKhwQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E25CB15@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 10:39:23 -0000 =20 Hi, >>So, the main issue (at least not from our perspective) is=20 >>not the code it takes to implement TCP/MSRP B2BUA=20 >>functionaltiy, but the performance impacts when one has to use it. >=20 >I wonder whether small manufactures of routers (those which=20 >include painful SIP-ALG enabled by default) will be also=20 >capable of building such fallback mechanism (MSRP B2BUA). I don't know. But, they are maybe not even going to implement sessmatch, so= there is nothing we can do about it. The only thing WE can do is to describe how things need to be done in order= for things to work, and then let the market and competition take care of t= he rest. Regards, Christer= From christer.holmberg@ericsson.com Thu May 26 04:42:38 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B484130012 for ; Thu, 26 May 2011 04:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.319 X-Spam-Level: X-Spam-Status: No, score=-6.319 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcliITtaIz7y for ; Thu, 26 May 2011 04:42:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 115E7E06E2 for ; Thu, 26 May 2011 04:42:36 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-3c-4dde3cabd3b3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 08.F2.20773.BAC3EDD4; Thu, 26 May 2011 13:42:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 May 2011 13:42:35 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Thu, 26 May 2011 13:42:34 +0200 Thread-Topic: [Simple] Sessmatch products Thread-Index: AcwbisSnXxCHjaPGTWWuS6+EUr8tdAAAYLdg Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B5FDAE@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194E25CAA0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIMPLE \(SIP for Instant Messaging and Presence Leveraging Extensions\) WG" Subject: Re: [Simple] Sessmatch products X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 11:42:38 -0000 Hi,=20 >>There has been comments about the existence of sessmatch=20 >>products, so let me give some information from my own company. >=20 >Cool, real stuff :-) My task in standardization is to work on stuff that actually is intented to= be implemented :) >>The Ericsson's carrier class SBC currently supports running=20 >>in either sessmatch mode or TCP/MSRP B2BUA mode, and we=20 >>currently see no problem in implementing fallback.=20 >>=20 >>In sessmatch mode the troughput for MSRP packets is=20 >>line-interface wirespeed, while in MSRP B2BUA mode the=20 >>maximum throughput for MSRP packets is much lower. >>=20 >>One application we are using MSRP for is to transfer video=20 >>clips between user endpoints, and we would like to have the=20 >>option of not having to use B2BUA mode if it can be avoided.=20 >>=20 >>So, the main issue (at least not from our perspective) is=20 >>not the code it takes to implement TCP/MSRP B2BUA=20 >>functionaltiy, but the performance impacts when one has to use it. >>=20 >=20 >I understand. What about this: since your endpoints support=20 >sessmatch, the cheapest approach would be used by your ALG=20 >and the performance would be just fine. And if another=20 >endpoint that does not support sessmatch connects to your ALG=20 >the B2BUA mode would be used. Correct. As I said, we see no problem in doing fallback from sessmatch to B= 2BUA. Of course, due to the need to more resources, a fallback call could be reje= cted due to lack of resources. But, that is true for any type of call, and = any type of media. Even a sessmatch call could be rejected if there are not= enough resources to handle it. >Would that be reasonable for vendors? They can implement=20 >sessmatch on the endpoints but keeping the B2BUA mode for=20 >those who don't. I can only speak for my own company :) Regards, Christer= From wwwrun@ietfa.amsl.com Thu May 26 11:41:58 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 2A3F6130019; Thu, 26 May 2011 11:41:58 -0700 (PDT) From: The IESG To: isms-chairs@tools.ietf.org, Transport@ietfa.amsl.com, Subsystem@ietfa.amsl.com, for@ietfa.amsl.com, the@ietfa.amsl.com, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@tools.ietf.org (SNMP) (Expired) Message-Id: <20110526184158.2A3F6130019@ietfa.amsl.com> Date: Thu, 26 May 2011 11:41:58 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5590 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 18:41:58 -0000 'State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5590&rfc_flag=1 From wwwrun@ietfa.amsl.com Thu May 26 11:45:03 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id F186BE071F; Thu, 26 May 2011 11:45:02 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@ietfa.amsl.com, Context@ietfa.amsl.com (SNMP), EngineID@ietfa.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110526184502.F186BE071F@ietfa.amsl.com> Date: Thu, 26 May 2011 11:45:02 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 18:45:03 -0000 'State Changes to Approved-announcement to be sent from IESG Evaluation by Cindy Morgan' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From christer.holmberg@ericsson.com Mon May 30 12:40:28 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA377E070C for ; Mon, 30 May 2011 12:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.176 X-Spam-Level: X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYwG9MFagovR for ; Mon, 30 May 2011 12:40:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B1ACEE06AB for ; Mon, 30 May 2011 12:40:27 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-db-4de3f2aa6967 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A6.67.09774.AA2F3ED4; Mon, 30 May 2011 21:40:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 30 May 2011 21:40:25 +0200 From: Christer Holmberg To: "simple@ietf.org" Date: Mon, 30 May 2011 21:40:25 +0200 Thread-Topic: Sessmatch - an alternative approach Thread-Index: AQHMHwFs1TgLFYckr0ObZICiI9PJPw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 19:40:28 -0000 Hi, =20 Based on the issues that have been raised on sessmatch, I would like to pre= sent a modified version, that solves some of the raised issues related to s= ecurity, backward compability, usage of the Require header filed, and speci= fying of ALG behavior. It has the following advantages over the current ses= smatch mechanism: =20 1. Except for one case, that still requires MSRP B2BUA, it works with "lega= cy" SIP-ALGs (that only modify the SDP c/m line, but not the a=3Dpath) - EV= EN when a SIP-ALG is communicating with a RFC 4975 UA; =20 2. It works with name based authentication; =20 3. It works when a 4975 UA is behind a relay; 4. It works without a need for the offerer, or for the SIP-ALG, to use the = Require header field; and =20 5. It atually REMOVES the need to update the session matching procedure in = the first place :) =20 =20 The idea is based on the very original sessmatch proposal, where a sessmatc= h UA sends the TCP SYN for the MSRP connection based on the SDP c/m-line, r= ather than the a=3Dpath. BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI into the MSRP mes= sage, use it for name based authentication, and use if for session matching= - all according to existing RFC 4975 procedures. Let's look at how it works. Peer-to-peer (no SIP-ALG) ----------------------------- As in the current sessmatch proposal, there is still full backward compabil= ity. As the a=3Dpath and SDP c/m-line values will be identical, it doesn't = matter which the sessmatch UA uses for sending the TCP SYN.=20 (In fact, we could even specify that the sessmatch UA uses the a=3Dpath in = case it is identical to the SDP c/m-line, and everything would be identical= to RFC 4975.) SIP-ALG in the path --------------------- 1. A sessmatch UA sends a request that offers MSRP, and includes a sessmatc= h support indication (option-tag, SDP attribute, or whatever we choose). 2. The SIP-ALG modifies the SDP c/m-line of the offer, and the correspondin= g answer, in order to anchor the MSRP media. The a=3Dpath is NOT modified. 3. The sessmatch UA receives the answer from the remote UA. 4a. If the remote UA supports sessmatch, everthing is fine. Whoever is "act= ive" sends the TCP SYN according to the SDP c/m line (which points to the A= LG). 4b. If the remote UA does NOT support sessmatch, BUT is "passive" (default = if it does not support MSRP ACM), everything is fine. The sessmatch sends t= he TCP SYN according to the SDP c/m line (which points to the ALG). 4c. If the remote UA does NOT support sessmatch, AND is "active", things wi= ll NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try t= o send the TCP SYN according to a=3Dpath (which points to the sessmatch UA,= rather than to the ALG). 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending a = new offer where it does NOT include a sessmatch support indication. The SIP= -ALG, in order to support MSRP, will now have to enable MSRP B2BUA function= ality. It works the same in the other direction, where the 4975 UA sends the offer= . If the 4975 UA becomes "active", the sessmatch UA will have to send an of= fer without sessmatch indication. =20 Regards, =20 Christer= From ibc@aliax.net Mon May 30 13:52:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C53E0688 for ; Mon, 30 May 2011 13:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.251, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us2k5Qx2tdao for ; Mon, 30 May 2011 13:52:06 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9A3E067F for ; Mon, 30 May 2011 13:52:06 -0700 (PDT) Received: by qwc23 with SMTP id 23so2526712qwc.31 for ; Mon, 30 May 2011 13:52:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr3695995qcb.247.1306788725487; Mon, 30 May 2011 13:52:05 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Mon, 30 May 2011 13:52:05 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 30 May 2011 22:52:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 20:52:07 -0000 2011/5/30 Christer Holmberg : > Peer-to-peer (no SIP-ALG) > ----------------------------- > > As in the current sessmatch proposal, there is still full backward compab= ility. As the a=3Dpath and SDP c/m-line values will be identical, it doesn'= t matter which the sessmatch UA uses for sending the TCP SYN. This is an useful way not to "corrupt" the original and already standardized specification :) But in this case, I suggest that a sessmatch UA MUST use a separate "c" line for the MSRP connection. If not and if the UA also offers audio/video RTP, the ALG would force all the sessions to go through the ALG. Am I wrong? > SIP-ALG in the path > --------------------- > > > 1. A sessmatch UA sends a request that offers MSRP, and includes a sessma= tch support indication (option-tag, SDP attribute, or whatever we choose). > 2. The SIP-ALG modifies the SDP c/m-line of the offer, and the correspond= ing answer, in order to anchor the MSRP media. The a=3Dpath is NOT modified= . > 3. The sessmatch UA receives the answer from the remote UA. > 4a. If the remote UA supports sessmatch, everthing is fine. Whoever is "a= ctive" sends the TCP SYN according to the SDP c/m line (which points to the= ALG). > 4b. If the remote UA does NOT support sessmatch, BUT is "passive" (defaul= t if it does not support MSRP ACM), everything is fine. The sessmatch sends= the TCP SYN according to the SDP c/m line (which points to the ALG). In this case, it would occur that the remote (not supporting sessmatch) would receive the MSRP connection from an IP different than the indicated in the a=3Dpath. Could that suppose a problem? Just wondering. > 4c. If the remote UA does NOT support sessmatch, AND is "active", things = will NOT work (unless SIP-ALG bypass is allowed), as the remote UA will try= to send the TCP SYN according to a=3Dpath (which points to the sessmatch U= A, rather than to the ALG). In fact, this could always work (correct me if I'm wrong) if the ALG MUST allow bypass, so it could not (in this case) stay into the MSRP path. I see no other issues, are there? > 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by sending = a new offer where it does NOT include a sessmatch support indication. The S= IP-ALG, in order to support MSRP, will now have to enable MSRP B2BUA functi= onality. I'm still afraid of this fallback mechanism. Probably Ericsson SBC would implement it correctly, but I expect that other ALG boxes (let's say Chin-Chon-Xu Technologies, CheapBoxForever-Pro, Amateur-Xiun-Dragon-IPTech routers) will not implement it (or not correctly). So, wouldn't be better just to mandate ALG boxes to allow ALG-bypass? In fact, how is supposed an ALG could NOT allow bypass? how could it deny that an UA tries to connect to the URI in the a=3Dpath? Anyhow I don't understant point 5: a) How does sessmatch UA realize that the remote UA does not support sessma= tch? b) Let's suppose there is a good reply for a) (sure it's but I miss it now). Then sessamtch UA terminates the dialog (is it?) and sends a new INVITE not indicating sessmatch support. In this case the ALG could do just nothing (bypass as said above) and things would work. Of course, if due to NAT things cannot work (and there is no MSRP relay set for the remote UA) the ALG should become a MSRP B2BUA in order to make it to work. Please correct em if I'm wrong. > It works the same in the other direction, where the 4975 UA sends the off= er. If the 4975 UA becomes "active", the sessmatch UA will have to send an = offer without sessmatch indication. IMHO you are in the correct way now ;) Thanks a lot for your re-worked work. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Mon May 30 23:15:59 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85337E06D4 for ; Mon, 30 May 2011 23:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvFV180UMQck for ; Mon, 30 May 2011 23:15:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 28100E06BE for ; Mon, 30 May 2011 23:15:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-fc-4de4879c67a6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CE.17.09774.C9784ED4; Tue, 31 May 2011 08:15:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 31 May 2011 08:15:56 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 31 May 2011 08:15:54 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwfC3CVe378DotjQi6wLE8l+XWgDwASBdLQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 06:15:59 -0000 Hi,=20 >>Peer-to-peer (no SIP-ALG) >>----------------------------- >> >>As in the current sessmatch proposal, there is still full=20 >>backward compability. As the a=3Dpath and SDP c/m-line values=20 >>will be identical, it doesn't matter which the sessmatch UA=20 >>uses for sending the TCP SYN. >>=20 >This is an useful way not to "corrupt" the original and=20 >already standardized specification :) >=20 >But in this case, I suggest that a sessmatch UA MUST use a=20 >separate "c" line for the MSRP connection. If not and if the=20 >UA also offers audio/video RTP, the ALG would force all the=20 >sessions to go through the ALG. Am I wrong? Yes, I think so :) If the ALG only wants to anchor only SOME of the media streams, it can itse= lf "split" the session level "c" line into separate media level "c" lines. (From my personal expereince, though, if an ALG decides to anchor media, it= normally anchors ALL media.) >>SIP-ALG in the path >>--------------------- >> >> >> 1. A sessmatch UA sends a request that offers MSRP, and=20 >> includes a sessmatch support indication (option-tag, SDP=20 >> attribute, or whatever we choose). >>=20 >>=20 >> 2. The SIP-ALG modifies the SDP c/m-line of the offer, and=20 >> the corresponding answer, in order to anchor the MSRP media.=20 >> The a=3Dpath is NOT modified. >>=20 >>=20 >> 3. The sessmatch UA receives the answer from the remote UA. >>=20 >>=20 >> 4a. If the remote UA supports sessmatch, everthing is fine.=20 >> Whoever is "active" sends the TCP SYN according to the SDP=20 >> c/m line (which points to the ALG). >>=20 >>=20 >> 4b. If the remote UA does NOT support sessmatch, BUT is=20 >> "passive" (default if it does not support MSRP ACM),=20 >> everything is fine. The sessmatch sends the TCP SYN according=20 >> to the SDP c/m line (which points to the ALG). >=20 >In this case, it would occur that the remote (not supporting >sessmatch) would receive the MSRP connection from an IP=20 >different than the indicated in the a=3Dpath. Could that=20 >suppose a problem? Just wondering. I was thinking the same, but could not find any text saying that. According= to 4975 the a=3Dpath is used for sending TCP SYN, performing session match= ing and performing TLS name based authentication. So, the remote UA accepts the TCP connection, and then use authentication e= tc to verify the sender etc. (Also remember that, in SDP, the received IP address does not tell from whe= re a connection is supposed to come.) =20 >> 4c. If the remote UA does NOT support sessmatch, AND is=20 >> "active", things will NOT work (unless SIP-ALG bypass is=20 >> allowed), as the remote UA will try to send the TCP SYN=20 >> according to a=3Dpath (which points to the sessmatch UA, rather=20 >> than to the ALG). >=20 >In fact, this could always work (correct me if I'm wrong) if=20 >the ALG MUST allow bypass, so it could not (in this case)=20 >stay into the MSRP path. Yes. But, we cannot mandate bypass. There are reasons, whether we like them= or not, why ALGs anchor media, and we cannot change that fact. See more on= this at the end of the reply. Having said that, we can of course add some text saying that IF bypass is a= llowed and possible, there is no problem :) >>I see no other issues, are there? >> >> >> 5. In case of 4c, the sessmatch UA does a "fallback" to=20 >> 4975, by sending a new offer where it does NOT include a=20 >> sessmatch support indication. The SIP-ALG, in order to=20 >> support MSRP, will now have to enable MSRP B2BUA functionality. >=20 > I'm still afraid of this fallback mechanism. Probably=20 > Ericsson SBC would implement it correctly, but I expect that=20 > other ALG boxes (let's say Chin-Chon-Xu Technologies,=20 > CheapBoxForever-Pro, Amateur-Xiun-Dragon-IPTech routers) will=20 > not implement it (or not correctly). So, wouldn't be better=20 > just to mandate ALG boxes to allow ALG-bypass? In fact, how=20 > is supposed an ALG could NOT allow bypass? > how could it deny that an UA tries to connect to the URI in=20 > the a=3Dpath? The ALG may never even see the TCP SYN, as the a=3Dpath points towards the = sessmatch UA. Of course, if bypass is allowed, the sessmatch UA might get the TCP SYN, an= d everything works, but if bypass is not allowed there will probably be e.g= . some firewall somewhere that only passes traffic addressed towards the AL= G. In general, why would a provider buy an ALG that suddenly prevents customer= s to use a service - MSRP in this case? It is very easy for customers to ch= ange provider nowadays, so I think the market and competition will ensure t= hat things that are supposed to work will work.=20 Of course, if a provider does not want to allow MSRP in the first place, it= does not really matter what we specify :) Also, sometimes things wouldn't work if bypass was allowed, if the ALG perf= orms e.g functions related to NAT traversal, IP version interworking, and/o= r signalling compression/encryption (e.g. the IMS P-CSCF). =20 >Anyhow I don't understant point 5: >=20 >a) How does sessmatch UA realize that the remote UA does not=20 >support sessmatch? There is no indicator (option-tag, SDP attribute, etc) in the response.=20 I guess I forgot to write that, in case of 4a, the remote UA inserts a sess= match support indicator in the response. >b) Let's suppose there is a good reply for a) (sure it's but=20 >I miss it now). Then sessamtch UA terminates the dialog (is=20 >it?) and sends a new INVITE not indicating sessmatch support.=20 >In this case the ALG could do just nothing (bypass as said=20 >above) and things would work. Of course, if due to NAT things=20 >cannot work (and there is no MSRP relay set for the remote=20 >UA) the ALG should become a MSRP B2BUA in order to make it to work. >=20 >Please correct em if I'm wrong. I don't think you're wrong. However, the sessmatch UA does not necessarily have to terminate the dialog= . It could send the new offer in a re-INVITE/UPDATE within the existing dia= log, and the SIP-ALG would enable MSRP B2BUA. It is fully possible for an A= LG to do that mid-dialog. And, at least in cases where preconditions are us= ed, this would not even cause any additional signalling. But, we can of course let the sessmatch UA decide for himself whether he te= rminates the dialog or not. The important thing is that it sends a new offe= r without sessmatch support indication. >>It works the same in the other direction, where the 4975 UA=20 >>sends the offer. If the 4975 UA becomes "active", the=20 >>sessmatch UA will have to send an offer without sessmatch indication. >=20 >IMHO you are in the correct way now ;) >=20 >Thanks a lot for your re-worked work. Thank You for your comments :) I realize it is not 100% perfect, as there is one case where MSRP B2BUA is = still needed. But, I'm afraid this is the best I can offer :) I do think, however, that this would be a big step forward, as it does solv= e a number of issues that have previsouly been raised. Regards, Christer From ibc@aliax.net Tue May 31 03:28:31 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C5FE06D8 for ; Tue, 31 May 2011 03:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w02Qy5vbNXK4 for ; Tue, 31 May 2011 03:28:30 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87A21E06AE for ; Tue, 31 May 2011 03:28:30 -0700 (PDT) Received: by qyk29 with SMTP id 29so1222663qyk.10 for ; Tue, 31 May 2011 03:28:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.182.202 with SMTP id cd10mr4118838qcb.171.1306837709638; Tue, 31 May 2011 03:28:29 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 31 May 2011 03:28:29 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 31 May 2011 12:28:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 10:28:31 -0000 2011/5/31 Christer Holmberg : >>But in this case, I suggest that a sessmatch UA MUST use a >>separate "c" line for the MSRP connection. If not and if the >>UA also offers audio/video RTP, the ALG would force all the >>sessions to go through the ALG. Am I wrong? > > Yes, I think so :) > > If the ALG only wants to anchor only SOME of the media streams, it can it= self "split" the session level "c" line into separate media level "c" lines= . > > (From my personal expereince, though, if an ALG decides to anchor media, = it normally anchors ALL media.) Sure, but in case of just wanting to anchor MSRP media, I expect it would be much easier the UA to set a separate "c" line for MSRP rather than the AGL rewriting the SDP by adding a specific "c" line within MSRP section :) That's why I suggest "the seesmatch UA SHOULD set a separate "c" line for its offered MSRP media" in the specification. But maybe this is not so important. >>> 4b. If the remote UA does NOT support sessmatch, BUT is >>> "passive" (default if it does not support MSRP ACM), >>> everything is fine. The sessmatch sends the TCP SYN according >>> to the SDP c/m line (which points to the ALG). >> >>In this case, it would occur that the remote (not supporting >>sessmatch) would receive the MSRP connection from an IP >>different than the indicated in the a=3Dpath. Could that >>suppose a problem? Just wondering. > > I was thinking the same, but could not find any text saying that. Accordi= ng to 4975 the a=3Dpath is used for sending TCP SYN, performing session mat= ching and performing TLS name based authentication. Neither I'm aware of a text stating that it could be an issue. > So, the remote UA accepts the TCP connection, and then use authentication= etc to verify the sender etc. > > (Also remember that, in SDP, the received IP address does not tell from w= here a connection is supposed to come.) 100% right, so forget my objection. >>> 4c. If the remote UA does NOT support sessmatch, AND is >>> "active", things will NOT work (unless SIP-ALG bypass is >>> allowed), as the remote UA will try to send the TCP SYN >>> according to a=3Dpath (which points to the sessmatch UA, rather >>> than to the ALG). >> >>In fact, this could always work (correct me if I'm wrong) if >>the ALG MUST allow bypass, so it could not (in this case) >>stay into the MSRP path. > > Yes. But, we cannot mandate bypass. There are reasons, whether we like th= em or not, why ALGs anchor media, and we cannot change that fact. See more = on this at the end of the reply. Yes, network topology could "denny by itself" the bypass. I just meant that the ALG box is not supposed to "deny" it. > Having said that, we can of course add some text saying that IF bypass is= allowed and possible, there is no problem :) It would be nice. And in case the ALG is aware that without sessmatch things would not work, it could decide to behave as a MSRP B2BUA and so. But mandating (MUST) that the ALG becomes a MSRP B2BUA is a bit utopian IMHO. So with new changes in this spec, an ALG B2BUA doesn't break anymore MSRP relayes. In case of doble NAT scenarios where there is no MSRP relays and both UA's don't support sessmatch, then I suggest let things not work (ALG just does bypass and MSRP connection would just fail). It obvious that this scenario would also not work if the router is not an ALG so, why to mandate the ALG to become a MSRP B2BUA by specs? I don't think an ALG should be specifiied to make "magic" :) In the previous version of this draft, it could make sense (becoming a MSRP B2BUA) as the ALG did break normal MSRP scenarios, but now I see no reason for that. >> I'm still afraid of this fallback mechanism. Probably >> Ericsson SBC would implement it correctly, but I expect that >> other ALG boxes (let's say Chin-Chon-Xu Technologies, >> CheapBoxForever-Pro, Amateur-Xiun-Dragon-IPTech routers) will >> not implement it (or not correctly). So, wouldn't be better >> just to mandate ALG boxes to allow ALG-bypass? In fact, how >> is supposed an ALG could NOT allow bypass? >> how could it deny that an UA tries to connect to the URI in >> the a=3Dpath? > > The ALG may never even see the TCP SYN, as the a=3Dpath points towards th= e sessmatch UA. > > Of course, if bypass is allowed, the sessmatch UA might get the TCP SYN, = and everything works, but if bypass is not allowed there will probably be e= .g. some firewall somewhere that only passes traffic addressed towards the = ALG. So same as above. In such scenario MSRP would not work even if the router is not an ALG. Why to mandate that, in case the router is an ALG, it must become a MSRP B2BUA? >>a) How does sessmatch UA realize that the remote UA does not >>support sessmatch? > > There is no indicator (option-tag, SDP attribute, etc) in the response. > > I guess I forgot to write that, in case of 4a, the remote UA inserts a se= ssmatch support indicator in the response. Ok. >>b) Let's suppose there is a good reply for a) (sure it's but >>I miss it now). Then sessamtch UA terminates the dialog (is >>it?) and sends a new INVITE not indicating sessmatch support. >>In this case the ALG could do just nothing (bypass as said >>above) and things would work. Of course, if due to NAT things >>cannot work (and there is no MSRP relay set for the remote >>UA) the ALG should become a MSRP B2BUA in order to make it to work. >> >>Please correct em if I'm wrong. > > I don't think you're wrong. > > However, the sessmatch UA does not necessarily have to terminate the dial= og. It could send the new offer in a re-INVITE/UPDATE within the existing d= ialog, and the SIP-ALG would enable MSRP B2BUA. It is fully possible for an= ALG to do that mid-dialog. And, at least in cases where preconditions are = used, this would not even cause any additional signalling. > > But, we can of course let the sessmatch UA decide for himself whether he = terminates the dialog or not. The important thing is that it sends a new of= fer without sessmatch support indication. Ok. > I realize it is not 100% perfect, as there is one case where MSRP B2BUA i= s still needed. But, I'm afraid this is the best I can offer :) Correct me if I'm wrong. I'm saying same as above again: In the case you mean MSRP just would work if the ALG would become a MSRP B2BUA, am I right? would MSRP work if the router is not an ALG? If not, I see no reason to mandate the ALG becoming a exotic MSRP B2BUA. Honestly I feel much more comfortable with this spec not breaking the existing world rather than trying to solve all the problems of the world :) > I do think, however, that this would be a big step forward, as it does so= lve a number of issues that have previsouly been raised. Sure :) Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 31 10:50:01 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A858AE06D9 for ; Tue, 31 May 2011 10:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87zgNHJcGB6Q for ; Tue, 31 May 2011 10:50:00 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 39B95E06C0 for ; Tue, 31 May 2011 10:50:00 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a6-4de52a465faa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D7.FE.20773.64A25ED4; Tue, 31 May 2011 19:49:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 31 May 2011 19:49:58 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Tue, 31 May 2011 19:49:58 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwffX0YH2nAojK6SN6llIdInxrNggAOQCk7 Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 17:50:01 -0000 Hi, >>>But in this case, I suggest that a sessmatch UA MUST use a >>>separate "c" line for the MSRP connection. If not and if the >>>UA also offers audio/video RTP, the ALG would force all the >>>sessions to go through the ALG. Am I wrong? >> >> Yes, I think so :) >> >> If the ALG only wants to anchor only SOME of the media streams, it can i= tself "split" the session level "c" line into separate media level "c" line= s. >> >> (From my personal expereince, though, if an ALG decides to anchor media,= it normally anchors ALL media.) > >Sure, but in case of just wanting to anchor MSRP media, I expect it >would be much easier the UA to set a separate "c" line for MSRP rather >than the AGL rewriting the SDP by adding a specific "c" line within >MSRP section :) Sure, but that applies to all types of media. >That's why I suggest "the seesmatch UA SHOULD set a separate "c" line >for its offered MSRP media" in the specification. But maybe this is >not so important. I personally think such a statement would be more useful e.g. in a general = offer/answer document. >>>> 4c. If the remote UA does NOT support sessmatch, AND is >>>> "active", things will NOT work (unless SIP-ALG bypass is >>>> allowed), as the remote UA will try to send the TCP SYN >>>> according to a=3Dpath (which points to the sessmatch UA, rather >>>> than to the ALG). >>> >>>In fact, this could always work (correct me if I'm wrong) if >>>the ALG MUST allow bypass, so it could not (in this case) >>>stay into the MSRP path. >> >> Yes. But, we cannot mandate bypass. There are reasons, whether we like t= hem or not, why ALGs anchor media, and we cannot change that fact. See more= on this at the end of the reply. > >Yes, network topology could "denny by itself" the bypass. I just meant >that the ALG box is not supposed to "deny" it. > >>Having said that, we can of course add some text saying that IF bypass is= allowed and possible, there is no problem :) > >It would be nice. And in case the ALG is aware that without sessmatch >things would not work, it could decide to behave as a MSRP B2BUA and >so. But mandating (MUST) that the ALG becomes a MSRP B2BUA is a bit >utopian IMHO. It all depends whether the ALG needs (based on operator policy and/or pure = technical reasons) to anchor the media or not. >So with new changes in this spec, an ALG B2BUA doesn't break anymore >MSRP relayes. In case of doble NAT scenarios where there is no MSRP >relays and both UA's don't support sessmatch, then I suggest let >things not work (ALG just does bypass and MSRP connection would just >fail). It obvious that this scenario would also not work if the router >is not an ALG so, why to mandate the ALG to become a MSRP B2BUA by >specs? I don't think an ALG should be specifiied to make "magic" :) Routers don't modify SIP messages, or anchor media - they normally only for= wards IP packages, so they would not need to become MSPR B2BUAs. >In the previous version of this draft, it could make sense (becoming a >MSRP B2BUA) as the ALG did break normal MSRP scenarios, but now I see >no reason for that. The reason is the same (eventhough due to different technical reasons): in = order to be able to provide an MSRP service (in cases where media anchoring= is needed). >>> I'm still afraid of this fallback mechanism. Probably >>> Ericsson SBC would implement it correctly, but I expect that >>> other ALG boxes (let's say Chin-Chon-Xu Technologies, >>> CheapBoxForever-Pro, Amateur-Xiun-Dragon-IPTech routers) will >>> not implement it (or not correctly). So, wouldn't be better >>> just to mandate ALG boxes to allow ALG-bypass? In fact, how >>> is supposed an ALG could NOT allow bypass? >>> how could it deny that an UA tries to connect to the URI in >>> the a=3Dpath? >> >> The ALG may never even see the TCP SYN, as the a=3Dpath points towards t= he sessmatch UA. >> >> Of course, if bypass is allowed, the sessmatch UA might get the TCP SYN,= and everything works, but if bypass is not allowed there will probably be = e.g. some firewall somewhere that only passes traffic addressed towards the= ALG. > >So same as above. In such scenario MSRP would not work even if the >router is not an ALG. Why to mandate that, in case the router is an >ALG, it must become a MSRP B2BUA? IF the ALG needs to anchor media, and IF the ALG wants to support MSRP. >>I realize it is not 100% perfect, as there is one case where MSRP B2BUA i= s still needed. But, I'm afraid this is the best I can offer :) > >Correct me if I'm wrong. I'm saying same as above again: > >In the case you mean MSRP just would work if the ALG would become a >MSRP B2BUA, am I right? IF the ALG needs to anchor media, and does NOT allow (for whatever reasons)= bypass, yes. >would MSRP work if the router is not an ALG? >If not, I see no reason to mandate the ALG becoming a exotic MSRP B2BUA. As I said earlier, routers don't need to become MSRP B2BUAs. Only ALGs that= need to anchor MSRP will need to support MSRP B2BUA - as is the case alrea= dy today, with or without sessmatch :) >Honestly I feel much more comfortable with this spec not breaking the >existing world rather than trying to solve all the problems of the >world :) I'll wait and see if someone else has a different opinion, before updating = the draft. It will require quite much re-wording. Also, we may have to change name of the mechanism, as we aren't really talk= ing about session matching anymore :) Regards, Christer= From wwwrun@ietfa.amsl.com Tue May 31 13:32:34 2011 Return-Path: X-Original-To: Simple Delivered-To: Simple@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id 220A5E0871; Tue, 31 May 2011 13:32:34 -0700 (PDT) From: The IESG To: opsawg-chairs@tools.ietf.org, Simple@ietfa.amsl.com, Network@ietfa.amsl.com, Management@ietfa.amsl.com, Protocol@ietfa.amsl.com, Context@ietfa.amsl.com (SNMP), EngineID@ietfa.amsl.com, Discovery@tools.ietf.org (Expired) Message-Id: <20110531203234.220A5E0871@ietfa.amsl.com> Date: Tue, 31 May 2011 13:32:34 -0700 (PDT) Subject: [Simple] ID Tracker State Update Notice: RFC 5343 X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf-secretariat-reply@ietf.org List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 20:32:34 -0000 'State Changes to Approved-announcement sent from Approved-announcement to be sent by Amy Vezza' ID Tracker URL: https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=5343&rfc_flag=1 From ben@estacado.net Tue May 31 14:32:56 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB24E08D1 for ; Tue, 31 May 2011 14:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAZfVig1N5dD for ; Tue, 31 May 2011 14:32:55 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by ietfa.amsl.com (Postfix) with ESMTP id 81E35E08BA for ; Tue, 31 May 2011 14:32:53 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p4VLWeX3044627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 31 May 2011 16:32:47 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 31 May 2011 16:32:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 21:32:56 -0000 Hi, How does this work when the peer is behind an MSRP Relay? Keep in mind = that, in this case, the c/m lines will refer to the endpoint itself, not = to the relay. Thanks! Ben. On May 30, 2011, at 2:40 PM, Christer Holmberg wrote: > Hi, >=20 > Based on the issues that have been raised on sessmatch, I would like = to present a modified version, that solves some of the raised issues = related to security, backward compability, usage of the Require header = filed, and specifying of ALG behavior. It has the following advantages = over the current sessmatch mechanism: >=20 > 1. Except for one case, that still requires MSRP B2BUA, it works with = "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the = a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; >=20 > 2. It works with name based authentication; >=20 > 3. It works when a 4975 UA is behind a relay; >=20 > 4. It works without a need for the offerer, or for the SIP-ALG, to use = the Require header field; and >=20 > 5. It atually REMOVES the need to update the session matching = procedure in the first place :) >=20 >=20 > The idea is based on the very original sessmatch proposal, where a = sessmatch UA sends the TCP SYN for the MSRP connection based on the SDP = c/m-line, rather than the a=3Dpath. >=20 > BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI into the = MSRP message, use it for name based authentication, and use if for = session matching - all according to existing RFC 4975 procedures. >=20 >=20 > Let's look at how it works. >=20 >=20 > Peer-to-peer (no SIP-ALG) > ----------------------------- >=20 > As in the current sessmatch proposal, there is still full backward = compability. As the a=3Dpath and SDP c/m-line values will be identical, = it doesn't matter which the sessmatch UA uses for sending the TCP SYN.=20= >=20 > (In fact, we could even specify that the sessmatch UA uses the a=3Dpath = in case it is identical to the SDP c/m-line, and everything would be = identical to RFC 4975.) >=20 >=20 > SIP-ALG in the path > --------------------- >=20 >=20 > 1. A sessmatch UA sends a request that offers MSRP, and includes a = sessmatch support indication (option-tag, SDP attribute, or whatever we = choose). >=20 > 2. The SIP-ALG modifies the SDP c/m-line of the offer, and the = corresponding answer, in order to anchor the MSRP media. The a=3Dpath is = NOT modified. >=20 > 3. The sessmatch UA receives the answer from the remote UA. >=20 > 4a. If the remote UA supports sessmatch, everthing is fine. Whoever is = "active" sends the TCP SYN according to the SDP c/m line (which points = to the ALG). >=20 > 4b. If the remote UA does NOT support sessmatch, BUT is "passive" = (default if it does not support MSRP ACM), everything is fine. The = sessmatch sends the TCP SYN according to the SDP c/m line (which points = to the ALG). >=20 > 4c. If the remote UA does NOT support sessmatch, AND is "active", = things will NOT work (unless SIP-ALG bypass is allowed), as the remote = UA will try to send the TCP SYN according to a=3Dpath (which points to = the sessmatch UA, rather than to the ALG). >=20 > 5. In case of 4c, the sessmatch UA does a "fallback" to 4975, by = sending a new offer where it does NOT include a sessmatch support = indication. The SIP-ALG, in order to support MSRP, will now have to = enable MSRP B2BUA functionality. >=20 >=20 > It works the same in the other direction, where the 4975 UA sends the = offer. If the 4975 UA becomes "active", the sessmatch UA will have to = send an offer without sessmatch indication. >=20 >=20 > Regards, >=20 > Christer > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From saul@ag-projects.com Tue May 31 23:15:07 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74001E066A for ; Tue, 31 May 2011 23:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j4aGaLRGIQ9 for ; Tue, 31 May 2011 23:15:06 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A3A74E0662 for ; Tue, 31 May 2011 23:15:05 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 254CCB01B9; Wed, 1 Jun 2011 08:15:02 +0200 (CEST) Received: from surfer-30-1-25.surfnet.iacbox (unknown [62.218.228.6]) by mail.sipthor.net (Postfix) with ESMTPSA id 1E601B017C; Wed, 1 Jun 2011 08:15:01 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:14:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <76E967BB-C645-4BC6-836C-8AF628A4EBA0@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:15:07 -0000 Hi, On May 31, 2011, at 7:49 PM, Christer Holmberg wrote: > Hi, >=20 >>>> But in this case, I suggest that a sessmatch UA MUST use a >>>> separate "c" line for the MSRP connection. If not and if the >>>> UA also offers audio/video RTP, the ALG would force all the >>>> sessions to go through the ALG. Am I wrong? >>>=20 >>> Yes, I think so :) >>>=20 >>> If the ALG only wants to anchor only SOME of the media streams, it = can itself "split" the session level "c" line into separate media level = "c" lines. >>>=20 >>> (=46rom my personal expereince, though, if an ALG decides to anchor = media, it normally anchors ALL media.) >>=20 >> Sure, but in case of just wanting to anchor MSRP media, I expect it >> would be much easier the UA to set a separate "c" line for MSRP = rather >> than the AGL rewriting the SDP by adding a specific "c" line within >> MSRP section :) >=20 > Sure, but that applies to all types of media. >=20 >> That's why I suggest "the seesmatch UA SHOULD set a separate "c" line >> for its offered MSRP media" in the specification. But maybe this is >> not so important. >=20 > I personally think such a statement would be more useful e.g. in a = general offer/answer document. >=20 >>>>> 4c. If the remote UA does NOT support sessmatch, AND is >>>>> "active", things will NOT work (unless SIP-ALG bypass is >>>>> allowed), as the remote UA will try to send the TCP SYN >>>>> according to a=3Dpath (which points to the sessmatch UA, rather >>>>> than to the ALG). >>>>=20 >>>> In fact, this could always work (correct me if I'm wrong) if >>>> the ALG MUST allow bypass, so it could not (in this case) >>>> stay into the MSRP path. >>>=20 >>> Yes. But, we cannot mandate bypass. There are reasons, whether we = like them or not, why ALGs anchor media, and we cannot change that fact. = See more on this at the end of the reply. >>=20 >> Yes, network topology could "denny by itself" the bypass. I just = meant >> that the ALG box is not supposed to "deny" it. >>=20 >>> Having said that, we can of course add some text saying that IF = bypass is allowed and possible, there is no problem :) >>=20 >> It would be nice. And in case the ALG is aware that without sessmatch >> things would not work, it could decide to behave as a MSRP B2BUA and >> so. But mandating (MUST) that the ALG becomes a MSRP B2BUA is a bit >> utopian IMHO. >=20 > It all depends whether the ALG needs (based on operator policy and/or = pure technical reasons) to anchor the media or not. >=20 Lets take the following case: Alice is NOT behind a MSRP ALG and is NOT = sessmatch capable. Bob is sessmatch enabled and he is behind one of = these ALGs. If Alice tries to establish a MSRP session towards Bob = (Alice being the active party) the ALG will know that it can't anchor = the media unless it falls back to B2BUA mode, right? So, assuming the answer to the previous question is 'yes', will the = fallback to B2BUA mode be mandatory for ALGs? > I'll wait and see if someone else has a different opinion, before = updating the draft. It will require quite much re-wording. >=20 I also feel better about the new approach. Looks like a way forward, = good work :-) > Also, we may have to change name of the mechanism, as we aren't really = talking about session matching anymore :) >=20 Definitely, sessmatch does not really apply as a name anymore :-) Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Tue May 31 23:16:25 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507C6E0697 for ; Tue, 31 May 2011 23:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fJINaP4Emjp for ; Tue, 31 May 2011 23:16:24 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 262C9E066A for ; Tue, 31 May 2011 23:16:23 -0700 (PDT) Received: by qwc23 with SMTP id 23so3336474qwc.31 for ; Tue, 31 May 2011 23:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.181.142 with SMTP id by14mr4900951qcb.247.1306908983109; Tue, 31 May 2011 23:16:23 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 31 May 2011 23:16:23 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:16:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:16:25 -0000 2011/5/31 Christer Holmberg : > Routers don't modify SIP messages, or anchor media - they normally only f= orwards IP packages Unfortunatelly routers do modify SIP messages as lot of them come with SIP ALG enabled by default: http://www.voip-info.org/wiki/view/Routers+SIP+ALG --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue May 31 23:22:57 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80BE06ED for ; Tue, 31 May 2011 23:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfnZEysJmIib for ; Tue, 31 May 2011 23:22:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 06BCDE0689 for ; Tue, 31 May 2011 23:22:55 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-40-4de5dabd1dcd Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.BC.20773.DBAD5ED4; Wed, 1 Jun 2011 08:22:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 1 Jun 2011 08:22:53 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 1 Jun 2011 08:22:52 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwgI263O4cTHl0DTxGEryj0soaueAAAMHpA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C31@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:22:57 -0000 Hi,=20 >> Routers don't modify SIP messages, or anchor media - they normally=20 >> only forwards IP packages >=20 >Unfortunatelly routers do modify SIP messages as lot of them=20 >come with SIP ALG enabled by default: >=20 > http://www.voip-info.org/wiki/view/Routers+SIP+ALG Sure, but then they aren't "plain" routers anymore. My point was that you d= on't need to add SIP-ALG functionality to your plain routers because of thi= s. Regards, Christer From ibc@aliax.net Tue May 31 23:23:42 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0365BE0748 for ; Tue, 31 May 2011 23:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgyCDWqv9YNa for ; Tue, 31 May 2011 23:23:41 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16212E0689 for ; Tue, 31 May 2011 23:23:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so3339099qwc.31 for ; Tue, 31 May 2011 23:23:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.237.21 with SMTP id km21mr4909009qcb.285.1306909420597; Tue, 31 May 2011 23:23:40 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 31 May 2011 23:23:40 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:23:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:23:42 -0000 2011/5/31 Christer Holmberg : > Also, we may have to change name of the mechanism, as we aren't really ta= lking about session matching anymore :) As a suggestion, correct me if I'm wrong but I'm pretty sure that this new specification provides no added value to existing scenarios/implementations in which there are not ALG boxes. So this specification is just useful for the case in which there is a MSRP-aware ALG box within the network (and such box wants to anchor the media). So I suggest including the word "ALG" somewhere in the draft title just for clarifications (i.e. "A technique for anchoring MSRP streams in ALG boxes"). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue May 31 23:32:34 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D972E075A for ; Tue, 31 May 2011 23:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWrQ19svKe3L for ; Tue, 31 May 2011 23:32:34 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFC19E074F for ; Tue, 31 May 2011 23:32:33 -0700 (PDT) Received: by qyk29 with SMTP id 29so1731300qyk.10 for ; Tue, 31 May 2011 23:32:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr4922405qci.209.1306909953272; Tue, 31 May 2011 23:32:33 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 31 May 2011 23:32:33 -0700 (PDT) In-Reply-To: <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> Date: Wed, 1 Jun 2011 08:32:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Ben Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:32:34 -0000 2011/5/31 Ben Campbell : > How does this work when the peer is behind an MSRP Relay? Keep in mind th= at, in this case, the c/m lines will refer to the endpoint itself, not to t= he relay. I would add another scenario: - Alice (not sessmatch UA) uses an outbount MSRP relay and wants to establish a MSRP session with Bob who is behind an ALG. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Tue May 31 23:36:50 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1983AE076A for ; Tue, 31 May 2011 23:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHd1jMHch-6Y for ; Tue, 31 May 2011 23:36:49 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 85FDCE065D for ; Tue, 31 May 2011 23:36:49 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 80B21B01B7; Wed, 1 Jun 2011 08:36:48 +0200 (CEST) Received: from surfer-30-1-25.surfnet.iacbox (unknown [62.218.228.6]) by mail.sipthor.net (Postfix) with ESMTPSA id 985F6B017D; Wed, 1 Jun 2011 08:36:47 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: Date: Wed, 1 Jun 2011 08:36:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <120C2252-9322-414D-862D-8FF3E1B34B82@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:36:50 -0000 Hi, On Jun 1, 2011, at 8:32 AM, I=F1aki Baz Castillo wrote: > 2011/5/31 Ben Campbell : >> How does this work when the peer is behind an MSRP Relay? Keep in = mind that, in this case, the c/m lines will refer to the endpoint = itself, not to the relay. >=20 > I would add another scenario: >=20 > - Alice (not sessmatch UA) uses an outbount MSRP relay and wants to > establish a MSRP session with Bob who is behind an ALG. >=20 I might be missing something, but does it really affect the fact that = Alice is using an outbound relay? It looks to me that it doesn't (alice = being NOT sessmatch capable). --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Tue May 31 23:49:21 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E025FE06E1 for ; Tue, 31 May 2011 23:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDcz8S0220pH for ; Tue, 31 May 2011 23:49:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 27356E06CD for ; Tue, 31 May 2011 23:49:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-7f-4de5e0f02cbc Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.09.20773.0F0E5ED4; Wed, 1 Jun 2011 08:49:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 1 Jun 2011 08:49:18 +0200 From: Christer Holmberg To: Saul Ibarra Corretge Date: Wed, 1 Jun 2011 08:49:17 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: AcwgIz90aFpZtxy/RVOGN6fsUrcmcwAAvM2g Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C73@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> <76E967BB-C645-4BC6-836C-8AF628A4EBA0@ag-projects.com> In-Reply-To: <76E967BB-C645-4BC6-836C-8AF628A4EBA0@ag-projects.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:49:22 -0000 Hi,=20 >Lets take the following case: Alice is NOT behind a MSRP ALG=20 >and is NOT sessmatch capable. Bob is sessmatch enabled and he=20 >is behind one of these ALGs. If Alice tries to establish a=20 >MSRP session towards Bob (Alice being the active party) the=20 >ALG will know that it can't anchor the media unless it falls=20 >back to B2BUA mode, right? It depends on whether Alice becomes "active" or "passive". If Alice becomes "passive", Bob will send the TCP SYN according to c-line (= which points to the ALG), and in that case there is no need for B2BUA mode. If Alice becomes "active", she will try to send the TCP SYN according to th= e a=3Dpath (which points to Bob - not the ALG), which often will fail. So, = the idea is that Bob sends a new offer, without the sessmatch indicator, in= order to trigger fallback to 4975. In that case, the ALG will have to enab= le B2BUA mode. >So, assuming the answer to the previous question is 'yes',=20 >will the fallback to B2BUA mode be mandatory for ALGs? Yes, it is still mandatory, for the case when the 4975 UA is "active". The = difference is that the cases where B2BUA mode is needed has decreased, whic= h is good because of the negative performance impacts it brings. Regards, Christer =20 From ibc@aliax.net Tue May 31 23:53:04 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9DBE06AD for ; Tue, 31 May 2011 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ev43TBZSv-ah for ; Tue, 31 May 2011 23:53:03 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5BCE0697 for ; Tue, 31 May 2011 23:53:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so3350394qwc.31 for ; Tue, 31 May 2011 23:53:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr4932413qci.209.1306911182934; Tue, 31 May 2011 23:53:02 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Tue, 31 May 2011 23:53:02 -0700 (PDT) In-Reply-To: <120C2252-9322-414D-862D-8FF3E1B34B82@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> <120C2252-9322-414D-862D-8FF3E1B34B82@ag-projects.com> Date: Wed, 1 Jun 2011 08:53:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Saul Ibarra Corretge Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:53:04 -0000 2011/6/1 Saul Ibarra Corretge : >> - Alice (not sessmatch UA) uses an outbount MSRP relay and wants to >> establish a MSRP session with Bob who is behind an ALG. > > I might be missing something, but does it really affect the fact that Ali= ce is using an outbound relay? It looks to me that it doesn't (alice being = NOT sessmatch capable). I just wonder whether the ALG could make something wrong when manipulating or inspecting the a=3Dpath line with various entries. I expect there is no problem, just wondering. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Tue May 31 23:56:46 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F02E06B6 for ; Tue, 31 May 2011 23:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.463 X-Spam-Level: X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82NV0A2Fg7V9 for ; Tue, 31 May 2011 23:56:45 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6D518E0697 for ; Tue, 31 May 2011 23:56:45 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7A7CEB01B7; Wed, 1 Jun 2011 08:56:43 +0200 (CEST) Received: from surfer-30-1-25.surfnet.iacbox (unknown [62.218.228.6]) by mail.sipthor.net (Postfix) with ESMTPSA id AE8ECB017D; Wed, 1 Jun 2011 08:56:43 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Saul Ibarra Corretge In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C73@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Jun 2011 08:56:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2322F281-5AFD-4162-A07B-944C53576324@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585194E2A6BF3@ESESSCMS0356.eemea.ericsson.se>, <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3F5@ESESSCMS0356.eemea.ericsson.se> <76E967BB-C645-4BC6-836C-8AF628A4EBA0@ag-projects.com> <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C73@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:56:46 -0000 Hi, On Jun 1, 2011, at 8:49 AM, Christer Holmberg wrote: >=20 > Hi,=20 >=20 >> Lets take the following case: Alice is NOT behind a MSRP ALG=20 >> and is NOT sessmatch capable. Bob is sessmatch enabled and he=20 >> is behind one of these ALGs. If Alice tries to establish a=20 >> MSRP session towards Bob (Alice being the active party) the=20 >> ALG will know that it can't anchor the media unless it falls=20 >> back to B2BUA mode, right? >=20 > It depends on whether Alice becomes "active" or "passive". >=20 > If Alice becomes "passive", Bob will send the TCP SYN according to = c-line (which points to the ALG), and in that case there is no need for = B2BUA mode. >=20 Ok. > If Alice becomes "active", she will try to send the TCP SYN according = to the a=3Dpath (which points to Bob - not the ALG), which often will = fail. So, the idea is that Bob sends a new offer, without the sessmatch = indicator, in order to trigger fallback to 4975. In that case, the ALG = will have to enable B2BUA mode. >=20 >> So, assuming the answer to the previous question is 'yes',=20 >> will the fallback to B2BUA mode be mandatory for ALGs? >=20 > Yes, it is still mandatory, for the case when the 4975 UA is "active". = The difference is that the cases where B2BUA mode is needed has = decreased, which is good because of the negative performance impacts it = brings. >=20 Great! I really like that we have this as a must, it means we have no = breakage when users behind an ALG and users not behind an ALG interact = with each other :-) Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Tue May 31 23:58:36 2011 Return-Path: X-Original-To: simple@ietfa.amsl.com Delivered-To: simple@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A521CE06B6 for ; Tue, 31 May 2011 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffaODNUQzzuQ for ; Tue, 31 May 2011 23:58:35 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 43A88E0697 for ; Tue, 31 May 2011 23:58:35 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-94-4de5e319b85b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.72.09774.913E5ED4; Wed, 1 Jun 2011 08:58:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 1 Jun 2011 08:58:32 +0200 From: Christer Holmberg To: Ben Campbell Date: Wed, 1 Jun 2011 08:58:31 +0200 Thread-Topic: [Simple] Sessmatch - an alternative approach Thread-Index: Acwf2kvKZsy5Z3jcT32kGst7Z3dT3QATisjA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E2E4C86@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585194DF6A3EB@ESESSCMS0356.eemea.ericsson.se> <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.net> In-Reply-To: <9F1B808B-9548-4A87-A303-CB789B25C5E1@estacado.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 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Sessmatch - an alternative approach X-BeenThere: simple@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP for Instant Messaging and Presence Leveraging Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 06:58:36 -0000 Hi Ben,=20 >How does this work when the peer is behind an MSRP Relay?=20 >Keep in mind that, in this case, the c/m lines will refer to=20 >the endpoint itself, not to the relay. You are probably right. If the 4975 UA is behind a relay, the sessmatch UA = needs to trigger a fallback to 4975 (in a similar way as when the 4975 UA i= s "active"). The sessmatch UA can do if it detects that the remote SDP cont= ains multiple a=3Dpath attributes, indicating that there is relay(s) in the= path. The reason is that the 4975 UA has inserted its own address in the SDP c-li= ne (at least I can't find text in RFC 4976 which says otherwise), so the AL= G would try to connect to the 4975 UA rather than the relay. Good point! Regards, Christer > On May 30, 2011, at 2:40 PM, Christer Holmberg wrote: >=20 > > Hi, > >=20 > > Based on the issues that have been raised on sessmatch, I=20 > would like to present a modified version, that solves some of=20 > the raised issues related to security, backward compability,=20 > usage of the Require header filed, and specifying of ALG=20 > behavior. It has the following advantages over the current=20 > sessmatch mechanism: > >=20 > > 1. Except for one case, that still requires MSRP B2BUA, it=20 > works with=20 > > "legacy" SIP-ALGs (that only modify the SDP c/m line, but not the=20 > > a=3Dpath) - EVEN when a SIP-ALG is communicating with a RFC 4975 UA; > >=20 > > 2. It works with name based authentication; > >=20 > > 3. It works when a 4975 UA is behind a relay; > >=20 > > 4. It works without a need for the offerer, or for the=20 > SIP-ALG, to use=20 > > the Require header field; and > >=20 > > 5. It atually REMOVES the need to update the session matching=20 > > procedure in the first place :) > >=20 > >=20 > > The idea is based on the very original sessmatch proposal,=20 > where a sessmatch UA sends the TCP SYN for the MSRP=20 > connection based on the SDP c/m-line, rather than the a=3Dpath. > >=20 > > BUT, the sessmatch UA still inserts the a=3Dpath MSRP URI=20 > into the MSRP message, use it for name based authentication,=20 > and use if for session matching - all according to existing=20 > RFC 4975 procedures. > >=20 > >=20 > > Let's look at how it works. > >=20 > >=20 > > Peer-to-peer (no SIP-ALG) > > ----------------------------- > >=20 > > As in the current sessmatch proposal, there is still full=20 > backward compability. As the a=3Dpath and SDP c/m-line values=20 > will be identical, it doesn't matter which the sessmatch UA=20 > uses for sending the TCP SYN.=20 > >=20 > > (In fact, we could even specify that the sessmatch UA uses=20 > the a=3Dpath=20 > > in case it is identical to the SDP c/m-line, and everything=20 > would be=20 > > identical to RFC 4975.) > >=20 > >=20 > > SIP-ALG in the path > > --------------------- > >=20 > >=20 > > 1. A sessmatch UA sends a request that offers MSRP, and=20 > includes a sessmatch support indication (option-tag, SDP=20 > attribute, or whatever we choose). > >=20 > > 2. The SIP-ALG modifies the SDP c/m-line of the offer, and=20 > the corresponding answer, in order to anchor the MSRP media.=20 > The a=3Dpath is NOT modified. > >=20 > > 3. The sessmatch UA receives the answer from the remote UA. > >=20 > > 4a. If the remote UA supports sessmatch, everthing is fine.=20 > Whoever is "active" sends the TCP SYN according to the SDP=20 > c/m line (which points to the ALG). > >=20 > > 4b. If the remote UA does NOT support sessmatch, BUT is=20 > "passive" (default if it does not support MSRP ACM),=20 > everything is fine. The sessmatch sends the TCP SYN according=20 > to the SDP c/m line (which points to the ALG). > >=20 > > 4c. If the remote UA does NOT support sessmatch, AND is=20 > "active", things will NOT work (unless SIP-ALG bypass is=20 > allowed), as the remote UA will try to send the TCP SYN=20 > according to a=3Dpath (which points to the sessmatch UA, rather=20 > than to the ALG). > >=20 > > 5. In case of 4c, the sessmatch UA does a "fallback" to=20 > 4975, by sending a new offer where it does NOT include a=20 > sessmatch support indication. The SIP-ALG, in order to=20 > support MSRP, will now have to enable MSRP B2BUA functionality. > >=20 > >=20 > > It works the same in the other direction, where the 4975 UA=20 > sends the offer. If the 4975 UA becomes "active", the=20 > sessmatch UA will have to send an offer without sessmatch indication. > >=20 > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > Simple mailing list > > Simple@ietf.org > > https://www.ietf.org/mailman/listinfo/simple >=20 > =