From eburger@standardstrack.com Fri Jul 1 15:33: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 91C5911E814B for ; Fri, 1 Jul 2011 15:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 PJ0WFxPfBcJF for ; Fri, 1 Jul 2011 15:33:31 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id DB81511E809D for ; Fri, 1 Jul 2011 15:33:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:From:Content-Type:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=Pfrq0zO9wgxwiBk48EE9QFiE7ciHhHr5RHSlEQW/ohJI9bW/s1jLibxP5ugbE81w9+ek/qxGZGntO+WU4ZLzHWf/W2yqkRhIwZXh63hAIF5ZVmroJHG+/lKgbyh4iC1z; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.126]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QcmHB-0007RW-Oc for simple@ietf.org; Fri, 01 Jul 2011 15:33:30 -0700 From: Eric Burger Content-Type: multipart/signed; boundary=Apple-Mail-119-539925654; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 1 Jul 2011 18:33:27 -0400 Message-Id: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com> To: simple@ietf.org 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 - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Simple] External Review 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: Fri, 01 Jul 2011 22:33:32 -0000 --Apple-Mail-119-539925654 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I was asked by the SIMPLE Work Group Chair to review the Internet Draft, = Session Matching Update for the Message Session Relay Protocol (MSRP). This document describes the behavior of a half-way kind of new network = element, the half-application layer gateway (ALG). I call this a = half-ALG because a real ALG, in the SIP world, is a back-to-back user = agent, or B2BUA. In short, this draft is an advertisement for XMPP. The draft proposes a = quasi-but-not-at-all end-to-end protocol to enable middle boxes to relay = an MSRP stream by hacking the signaling to the point there really is a = new session. In fact, there is a new session, but the draft is = proposing a session to correlate the first session on one side of the = half-ALG with the other side. I would offer the applicability statement, = saying that this draft addresses the situation where there is deliberate = network impairment and partition, due to the presence of these = half-ALGs, immediately indicates that we are not talking about an = Internet topology, but some proprietary topology that happens to use the = IP for transport. I suppose this extension would be acceptable if the half-ALG is required = to cryptographically identify itself and either end point can opt out. = However, if opting out means no message goes through, then by definition = we are not in the Internet, and such an extension would be out of scope = for the IETF. There are a host of nits, like the document's abbreviation being MSRP = and bizarre formatting of section 7.1, but given the issues above, are = true nits.= --Apple-Mail-119-539925654 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MDEyMjMzMjdaMCMGCSqGSIb3DQEJ BDEWBBRZ/nR6uNZHXdPj1VwC3CmiWBw2lzCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAHitftxyWETD3D+28g+NlONlilCEqRUO/AzG0utfYiK0sV5T hihre4hbHz46sr+3JmTuHRtZTLBlxH6X+CdVvIMLeiL9hRNhZO4MRpU9x2uCYJLcm8g+13IFyrNu j/iAETaO6xofkBoA462WnhtmctfBQGc3BG4A12OIB3SCrVvKzP9ciE7A+hfguuRQTJjqA2vZ/kvT luLB4VHe0YvNC2tekcyrGI5RmCCOgItBGFWqn3Db/7mRTYreJZln64je7uHIdXejob1DMF6lNWT+ 4IVMxCPAfri4Ci910mRdRyH/LJQ6gUK2TwBH4DEkTjuItFYVTCS2mhIqL23DLuxVTwQAAAAAAAA= --Apple-Mail-119-539925654-- From christer.holmberg@ericsson.com Fri Jul 1 16:23: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 029531F0C3B for ; Fri, 1 Jul 2011 16:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 RELDjFmGn4oL for ; Fri, 1 Jul 2011 16:23:15 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9634521F85BA for ; Fri, 1 Jul 2011 16:23:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-bb-4e0e56ddc1d3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 53.87.20773.DD65E0E4; Sat, 2 Jul 2011 01:23:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 2 Jul 2011 01:23:08 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Sat, 2 Jul 2011 01:22:29 +0200 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: Acw3QWHTVSWjV+3CRQi38e5af7f0TwBBF0TQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FB5@ESESSCMS0356.eemea.ericsson.se> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> <72FE9E02-5126-4B9E-86E8-45433872FAC3@ag-projects.com> <5BE78AB8-75F1-401D-AB68-86FDD98E8B1B@acmepacket.com> <1DBB8711-D171-4DE2-A08E-A73AA1935F78@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 WG Subject: Re: [Simple] Consensus Call on sessmatch-13 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: Fri, 01 Jul 2011 23:23:16 -0000 Hi, >>I see no need for changing what RFC6135 says. What about something like: = "MSRP endpoints supporting >>this specification MUST become active upon rec= eiving an offer with 'actpass' " Would that be reasonable >>for you? > >This should be the way to go. Sounds good. Regards, Christer= From ben@estacado.net Mon Jul 11 12:58: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 C922511E8101 for ; Mon, 11 Jul 2011 12:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[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 jQ6cnpy4CZiS for ; Mon, 11 Jul 2011 12:58:28 -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 8D1DD11E809B for ; Mon, 11 Jul 2011 12:58:27 -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 p6BJwLTs001320 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jul 2011 14:58:22 -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: <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> Date: Mon, 11 Jul 2011 14:58:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <57F6E8A3-6751-40A4-B218-856DBD578385@estacado.net> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com><580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se> To: Atle Monrad X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] Consensus Call on sessmatch-13 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, 11 Jul 2011 19:58:28 -0000 Hi Atle, By "constructive proposal", do you mean the consensus call itself, or = did you mean to concur with my comment about wanting to understand the = scenarios better? Thanks! Ben. On Jun 28, 2011, at 6:00 AM, Atle Monrad wrote: > +1 from me aswell >=20 > Thanks to Ben for a constructive proposal ! >=20 > /atle >=20 >=20 > ________________________________=20 >=20 >=20 > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management=20 > Ericsson >=20 >=20 >=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of DOLLY, MARTIN C (ATTSI) > Sent: 28. juni 2011 00:33 > To: Nancy Greene; simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 >=20 > +1 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Nancy Greene > Sent: Monday, June 27, 2011 12:32 PM > To: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 >=20 > I also support sessmatch-13 >=20 > Nancy=20 >=20 > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On = Behalf Of Hadriel Kaplan > Sent: June-27-11 12:27 PM > To: > Cc: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 >=20 >=20 > +1 >=20 >=20 > On Jun 27, 2011, at 5:26 AM, = wrote: >=20 >> Hi, >> Yes I think that is the right direction to go. >>=20 >> Roland >>=20 >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im=20 >>> Auftrag von Ben Campbell >>> Gesendet: Freitag, 24. Juni 2011 20:45 >>> An: Simple WG >>> Betreff: [Simple] Consensus Call on sessmatch-13 >>>=20 >>> (as chair) >>>=20 >>> Hi, >>>=20 >>> The latest version of the sessmatch draft ( >>> draft-ietf-simple-msrp-sessmatch-13) is a significant change of=20 >>> direction from older version. The essential difference is that the=20= >>> new version involves compliant endpoints using the SDP m and c lines=20= >>> to establish TCP connections, rather than the previous approach of=20= >>> making clients more resilient to a middlebox changing an MSRP URI in=20= >>> the a=3Dpath attribute. The draft refers to this new approach as = CEMA. >>>=20 >>> Do people thinks this is the right direction to take this work? I'm=20= >>> not asking if the draft is perfect and ready to go--we certainly=20 >>> expect discussion and potential changes in the details. The point is=20= >>> to decide if we should move forward with the CEMA approach instead = of=20 >>> the previous sessmatch approach. >>>=20 >>> (In a perfect world, we probably would put CEMA in a separate draft=20= >>> so the two could be compared. But unless people strongly object, I=20= >>> think we can still compare the approaches with the current draft >>> structure.) >>>=20 >>> Please send opinions and comments to the SIMPLE list no later than = 11=20 >>> July 2011. Sooner is better. (This is probably longer than we need,=20= >>> but I know we're into prime vacation time for a number of people,=20 >>> including myself. I've allotted extra time in hopes of getting more >>> comments) >>>=20 >>> Thanks! >>>=20 >>> Ben. >>> _______________________________________________ >>> 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 >=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 > _______________________________________________ > 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 ben@estacado.net Mon Jul 11 13:10:37 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 0C3BF21F8EFD for ; Mon, 11 Jul 2011 13:10:37 -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=[AWL=0.300, BAYES_00=-2.599] 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 FGoUudZm48Nt for ; Mon, 11 Jul 2011 13:10: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 96E9021F8F02 for ; Mon, 11 Jul 2011 13:10: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 p6BKATNG003850 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jul 2011 15:10: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: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com> Date: Mon, 11 Jul 2011 15:10:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@estacado.net> References: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Cc: Eric Burger Subject: Re: [Simple] External Review 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, 11 Jul 2011 20:10:37 -0000 (as chair) Would anyone care to respond to Eric's review? These are not comments we = can easily ignore. Do the changes in version 13 make a difference here? Thanks! Ben. On Jul 1, 2011, at 5:33 PM, Eric Burger wrote: > I was asked by the SIMPLE Work Group Chair to review the Internet = Draft, Session Matching Update for the Message Session Relay Protocol = (MSRP). >=20 > This document describes the behavior of a half-way kind of new network = element, the half-application layer gateway (ALG). I call this a = half-ALG because a real ALG, in the SIP world, is a back-to-back user = agent, or B2BUA. >=20 > In short, this draft is an advertisement for XMPP. The draft proposes = a quasi-but-not-at-all end-to-end protocol to enable middle boxes to = relay an MSRP stream by hacking the signaling to the point there really = is a new session. In fact, there is a new session, but the draft is = proposing a session to correlate the first session on one side of the = half-ALG with the other side. I would offer the applicability statement, = saying that this draft addresses the situation where there is deliberate = network impairment and partition, due to the presence of these = half-ALGs, immediately indicates that we are not talking about an = Internet topology, but some proprietary topology that happens to use the = IP for transport. >=20 > I suppose this extension would be acceptable if the half-ALG is = required to cryptographically identify itself and either end point can = opt out. However, if opting out means no message goes through, then by = definition we are not in the Internet, and such an extension would be = out of scope for the IETF. >=20 > There are a host of nits, like the document's abbreviation being MSRP = and bizarre formatting of section 7.1, but given the issues above, are = true nits._______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Mon Jul 11 13:23: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 2782211E81E6 for ; Mon, 11 Jul 2011 13:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.533 X-Spam-Level: X-Spam-Status: No, score=-6.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 yWwqrPkG-+Xu for ; Mon, 11 Jul 2011 13:23: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 C83D511E818F for ; Mon, 11 Jul 2011 13:23:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-d6-4e1b5ba4baed Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E4.F2.09774.4AB5B1E4; Mon, 11 Jul 2011 22:23:00 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 11 Jul 2011 22:23:00 +0200 From: Christer Holmberg To: Ben Campbell , Simple WG Date: Mon, 11 Jul 2011 22:22:59 +0200 Thread-Topic: [Simple] External Review of draft-ietf-simple-msrp-sessmatch-11 Thread-Index: AcxABrcKUTnpEGdPQ/mo86gSJ+huNgAAH0+O Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC8@ESESSCMS0356.eemea.ericsson.se> References: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com>, <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@estacado.net> In-Reply-To: <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@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: Eric Burger Subject: Re: [Simple] External Review 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, 11 Jul 2011 20:23:03 -0000 Hi, If I understand Eric's comments, they are not technical, so I *assume* ther= e is not much difference between -13 and earlier versions from that perspec= tive. However, Eric does seem to imply that we could cover this by adding some te= xt to the applicability statement. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben Ca= mpbell [ben@estacado.net] Sent: Monday, July 11, 2011 11:10 PM To: Simple WG Cc: Eric Burger Subject: Re: [Simple] External Review of draft-ietf-simple-msrp-sessmatch-1= 1 (as chair) Would anyone care to respond to Eric's review? These are not comments we ca= n easily ignore. Do the changes in version 13 make a difference here? Thanks! Ben. On Jul 1, 2011, at 5:33 PM, Eric Burger wrote: > I was asked by the SIMPLE Work Group Chair to review the Internet Draft, = Session Matching Update for the Message Session Relay Protocol (MSRP). > > This document describes the behavior of a half-way kind of new network el= ement, the half-application layer gateway (ALG). I call this a half-ALG be= cause a real ALG, in the SIP world, is a back-to-back user agent, or B2BUA. > > In short, this draft is an advertisement for XMPP. The draft proposes a = quasi-but-not-at-all end-to-end protocol to enable middle boxes to relay an= MSRP stream by hacking the signaling to the point there really is a new se= ssion. In fact, there is a new session, but the draft is proposing a sessi= on to correlate the first session on one side of the half-ALG with the othe= r side. I would offer the applicability statement, saying that this draft a= ddresses the situation where there is deliberate network impairment and par= tition, due to the presence of these half-ALGs, immediately indicates that = we are not talking about an Internet topology, but some proprietary topolog= y that happens to use the IP for transport. > > I suppose this extension would be acceptable if the half-ALG is required = to cryptographically identify itself and either end point can opt out. Howe= ver, if opting out means no message goes through, then by definition we are= not in the Internet, and such an extension would be out of scope for the I= ETF. > > There are a host of nits, like the document's abbreviation being MSRP and= bizarre formatting of section 7.1, but given the issues above, are true ni= ts._______________________________________________ > 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 Mon Jul 11 13:30: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 0048111E81E6 for ; Mon, 11 Jul 2011 13:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 1h3IpcDpambN for ; Mon, 11 Jul 2011 13:30:11 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DEA3F11E80AB for ; Mon, 11 Jul 2011 13:30:10 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-cc-4e1b5d51475d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BA.36.20773.15D5B1E4; Mon, 11 Jul 2011 22:30:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 11 Jul 2011 22:30:09 +0200 From: Christer Holmberg To: Ben Campbell , Atle Monrad Date: Mon, 11 Jul 2011 22:30:08 +0200 Thread-Topic: [Simple] Consensus Call on sessmatch-13 Thread-Index: AcxABOrM0xRBkgqiT7+H0KUBeRb9IwAALPjV Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC7@ESESSCMS0356.eemea.ericsson.se> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com><580BEA5E3B99744AB1F5BFF5E9A3C67D08AE0A6939@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A73C134@gaalpa1msgusr7e.ugd.att.com> <7A051DFAA46D0246A82293C7CEF621E9056B870089@ESESSCMS0352.eemea.ericsson.se>, <57F6E8A3-6751-40A4-B218-856DBD578385@estacado.net> In-Reply-To: <57F6E8A3-6751-40A4-B218-856DBD578385@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "simple@ietf.org" Subject: Re: [Simple] Consensus Call on sessmatch-13 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, 11 Jul 2011 20:30:12 -0000 Hi, In general, fallback is still needed in middlebox cases where a legacy enti= ty establishes the MSRP TCP connection, or where the UA is behind a relay. (If there are no middleboxes, procedures are according to 4975). Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben Ca= mpbell [ben@estacado.net] Sent: Monday, July 11, 2011 10:58 PM To: Atle Monrad Cc: simple@ietf.org Subject: Re: [Simple] Consensus Call on sessmatch-13 Hi Atle, By "constructive proposal", do you mean the consensus call itself, or did y= ou mean to concur with my comment about wanting to understand the scenarios= better? Thanks! Ben. On Jun 28, 2011, at 6:00 AM, Atle Monrad wrote: > +1 from me aswell > > Thanks to Ben for a constructive proposal ! > > /atle > > > ________________________________ > > > Atle Monrad > 3GPP CT Chairman > Standardization and Regulation, > Group Function Technology and Portfolio Management > Ericsson > > > > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of DOLLY, MARTIN C (ATTSI) > Sent: 28. juni 2011 00:33 > To: Nancy Greene; simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > +1 > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Nancy Greene > Sent: Monday, June 27, 2011 12:32 PM > To: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > I also support sessmatch-13 > > Nancy > > -----Original Message----- > From: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] On Behalf = Of Hadriel Kaplan > Sent: June-27-11 12:27 PM > To: > Cc: simple@ietf.org > Subject: Re: [Simple] Consensus Call on sessmatch-13 > > > +1 > > > On Jun 27, 2011, at 5:26 AM, = wrote: > >> Hi, >> Yes I think that is the right direction to go. >> >> Roland >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: simple-bounces@ietf.org [mailto:simple-bounces@ietf.org] Im >>> Auftrag von Ben Campbell >>> Gesendet: Freitag, 24. Juni 2011 20:45 >>> An: Simple WG >>> Betreff: [Simple] Consensus Call on sessmatch-13 >>> >>> (as chair) >>> >>> Hi, >>> >>> The latest version of the sessmatch draft ( >>> draft-ietf-simple-msrp-sessmatch-13) is a significant change of >>> direction from older version. The essential difference is that the >>> new version involves compliant endpoints using the SDP m and c lines >>> to establish TCP connections, rather than the previous approach of >>> making clients more resilient to a middlebox changing an MSRP URI in >>> the a=3Dpath attribute. The draft refers to this new approach as CEMA. >>> >>> Do people thinks this is the right direction to take this work? I'm >>> not asking if the draft is perfect and ready to go--we certainly >>> expect discussion and potential changes in the details. The point is >>> to decide if we should move forward with the CEMA approach instead of >>> the previous sessmatch approach. >>> >>> (In a perfect world, we probably would put CEMA in a separate draft >>> so the two could be compared. But unless people strongly object, I >>> think we can still compare the approaches with the current draft >>> structure.) >>> >>> Please send opinions and comments to the SIMPLE list no later than 11 >>> July 2011. Sooner is better. (This is probably longer than we need, >>> but I know we're into prime vacation time for a number of people, >>> including myself. I've allotted extra time in hopes of getting more >>> comments) >>> >>> Thanks! >>> >>> Ben. >>> _______________________________________________ >>> 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 > > _______________________________________________ > 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 > _______________________________________________ > 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 _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From eburger@standardstrack.com Mon Jul 11 14:20: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 7E06811E8288 for ; Mon, 11 Jul 2011 14:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.532 X-Spam-Level: X-Spam-Status: No, score=-100.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067, 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 A6ui2iXRkRwX for ; Mon, 11 Jul 2011 14:20:03 -0700 (PDT) Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1AE11E828A for ; Mon, 11 Jul 2011 14:20:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id 82C1434DED; Mon, 11 Jul 2011 17:20:01 -0400 (EDT) X-Virus-Scanned: by amavisd-new at cs.georgetown.edu Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h08meb5tCtI; Mon, 11 Jul 2011 17:19:53 -0400 (EDT) Received: from 65.95.240.10.in-addr.arpa (m265636d0.tmodns.net [208.54.86.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 5190E34B2C; Mon, 11 Jul 2011 17:19:53 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-207--747972868; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC8@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 11 Jul 2011 16:19:52 -0500 Message-Id: References: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com>, <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@estacado.net> <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC8@ESESSCMS0356.eemea.ericsson.se> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] External Review 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, 11 Jul 2011 21:20:03 -0000 --Apple-Mail-207--747972868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We seem to be a bit closer with this draft. However, two things puzzle = me. The first is that the draft does not mandate TLS. Without mandatory = TLS, let us call the draft what it is: "Lawful intercept (LI) Capability = for the Message Session Relay Protocol (MSRP)." Then the discussion of = man-in-the-middle attacks can move from an unfortunate side-effect to a = design decision. I would suggest mandating TLS and forcing a connection = drop if it is not available. The second puzzle brings me back to the question of what we are trying = to accomplish. This draft mandates the middlebox must be able to perform = as a B2BUA. That tells me such a middlebox will have the thousands of = lines of code required to implement a B2BUA. Moreover, the middlebox = will have a few thousand lines of code to implement the draft behavior. = Given the relationship between code complexity and latent defects, I = would expect the Security Considerations section to point out that = implementing this draft, in addition to the B2BUA functionality, which = the network element must implement anyway, reduces the practical = security of the device, any networks it is supposed to protect, and = Internet stability in general. On Jul 11, 2011, at 3:22 PM, Christer Holmberg wrote: > Hi, >=20 > If I understand Eric's comments, they are not technical, so I *assume* = there is not much difference between -13 and earlier versions from that = perspective. >=20 > However, Eric does seem to imply that we could cover this by adding = some text to the applicability statement. >=20 > Regards, >=20 > Christer >=20 > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of = Ben Campbell [ben@estacado.net] > Sent: Monday, July 11, 2011 11:10 PM > To: Simple WG > Cc: Eric Burger > Subject: Re: [Simple] External Review of = draft-ietf-simple-msrp-sessmatch-11 >=20 > (as chair) >=20 > Would anyone care to respond to Eric's review? These are not comments = we can easily ignore. Do the changes in version 13 make a difference = here? >=20 > Thanks! >=20 > Ben. >=20 >=20 > On Jul 1, 2011, at 5:33 PM, Eric Burger wrote: >=20 >> I was asked by the SIMPLE Work Group Chair to review the Internet = Draft, Session Matching Update for the Message Session Relay Protocol = (MSRP). >>=20 >> This document describes the behavior of a half-way kind of new = network element, the half-application layer gateway (ALG). I call this = a half-ALG because a real ALG, in the SIP world, is a back-to-back user = agent, or B2BUA. >>=20 >> In short, this draft is an advertisement for XMPP. The draft = proposes a quasi-but-not-at-all end-to-end protocol to enable middle = boxes to relay an MSRP stream by hacking the signaling to the point = there really is a new session. In fact, there is a new session, but the = draft is proposing a session to correlate the first session on one side = of the half-ALG with the other side. I would offer the applicability = statement, saying that this draft addresses the situation where there is = deliberate network impairment and partition, due to the presence of = these half-ALGs, immediately indicates that we are not talking about an = Internet topology, but some proprietary topology that happens to use the = IP for transport. >>=20 >> I suppose this extension would be acceptable if the half-ALG is = required to cryptographically identify itself and either end point can = opt out. However, if opting out means no message goes through, then by = definition we are not in the Internet, and such an extension would be = out of scope for the IETF. >>=20 >> There are a host of nits, like the document's abbreviation being MSRP = and bizarre formatting of section 7.1, but given the issues above, are = true nits._______________________________________________ >> 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 --Apple-Mail-207--747972868 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MTEyMTE5NTJaMCMGCSqGSIb3DQEJ BDEWBBRi3MoJsP6CxFxarjGYekM8uQTdDjCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAIKFBDepN+o6rspnPO2R8tHqnFkhitb2X27tk2NdB0IZkvPn mG0j/prEiS7AbC6nziBcCFrRTEzRxaSVNzEAXlQ9DmX1KViHSk47ppKE3mG4G+c5yXC2hiR8MwCo ivY3adyVXYNJ2KnU7pTi1WUijxBjY9U8TqxAG0OtWIn+KhNHX+kepwo0CKIGTmMxwVb+RFE/dn5w SzAS8GYdng9dtOBOiRwiN/aHfD1qBmbfvKKZoX2bV3icpSpRzbyZRZf2WcCvxOd/7k6E5rMeBStv Gq4glLlI+7qqopsehhlTi8GiVGE7oJA5W4FTFc6fh46cvdEhi8DfosrZor1LeRbG4p8AAAAAAAA= --Apple-Mail-207--747972868-- From ben@estacado.net Tue Jul 12 13:20: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 17BBC9E802C for ; Tue, 12 Jul 2011 13:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=-0.200, 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 bF2V05byB+vH for ; Tue, 12 Jul 2011 13:20:39 -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 DC8A99E801C for ; Tue, 12 Jul 2011 13:20:38 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by estacado.net (8.14.3/8.14.3) with ESMTP id p6CKKSr6091412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Jul 2011 15:20:34 -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: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> Date: Tue, 12 Jul 2011 15:20:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <550EA63E-287E-4F27-BF4F-F345541EEE25@estacado.net> References: <5A1EB11A-9A1D-4B62-B83A-1BBB0F4710FE@nostrum.com> To: Simple WG X-Mailer: Apple Mail (2.1084) Subject: Re: [Simple] Consensus Call on sessmatch-13 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, 12 Jul 2011 20:20:40 -0000 (as chair) I read the resulting thread as rough consensus to follow the general = direction of the CEMA approach in sessmatch-13. We've seen some comments = on details, and some requests for more analysis of scenarios. We've also = seen comments questioning the general applicability of the work in a = separate thread. Please continue with those conversations. While we have agenda time for this in Quebec City, it would be even = better to get as much work done as possible before the face to face = meeting :-) Thanks! Ben. On Jun 24, 2011, at 1:45 PM, Ben Campbell wrote: > (as chair) >=20 > Hi, >=20 > The latest version of the sessmatch draft ( = draft-ietf-simple-msrp-sessmatch-13) is a significant change of = direction from older version. The essential difference is that the new = version involves compliant endpoints using the SDP m and c lines to = establish TCP connections, rather than the previous approach of making = clients more resilient to a middlebox changing an MSRP URI in the a=3Dpath= attribute. The draft refers to this new approach as CEMA. >=20 > Do people thinks this is the right direction to take this work? I'm = not asking if the draft is perfect and ready to go--we certainly expect = discussion and potential changes in the details. The point is to decide = if we should move forward with the CEMA approach instead of the previous = sessmatch approach. >=20 > (In a perfect world, we probably would put CEMA in a separate draft so = the two could be compared. But unless people strongly object, I think we = can still compare the approaches with the current draft structure.) >=20 > Please send opinions and comments to the SIMPLE list no later than 11 = July 2011. Sooner is better. (This is probably longer than we need, but = I know we're into prime vacation time for a number of people, including = myself. I've allotted extra time in hopes of getting more comments) >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From christer.holmberg@ericsson.com Tue Jul 12 13:57: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 F197011E8078 for ; Tue, 12 Jul 2011 13:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.519 X-Spam-Level: X-Spam-Status: No, score=-6.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4gACOSGp61u0 for ; Tue, 12 Jul 2011 13:57: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 A85A411E8070 for ; Tue, 12 Jul 2011 13:57:23 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a8-4e1cb5321968 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 18.B9.20773.235BC1E4; Tue, 12 Jul 2011 22:57:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 12 Jul 2011 22:57:22 +0200 From: Christer Holmberg To: Eric Burger , Simple WG Date: Tue, 12 Jul 2011 22:57:22 +0200 Thread-Topic: [Simple] External Review of draft-ietf-simple-msrp-sessmatch-11 Thread-Index: AcxAEHEFFJj/B4cgQjmhl1rXYYc2KQAwt+8W Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FD4@ESESSCMS0356.eemea.ericsson.se> References: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com>, <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@estacado.net> <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC8@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] External Review 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: Tue, 12 Jul 2011 20:57:25 -0000 Hi Eric, >We seem to be a bit closer with this draft. However, two things puzzle me= . > >The first is that the draft does not mandate TLS. Without mandatory TLS, = let us call the draft what it is: "Lawful intercept (LI) Capability for the= Message Session Relay Protocol (MSRP)." Then the discussion of man-in-the= -middle attacks can move from an unfortunate=20 >side-effect to a design decision. I would suggest mandating TLS and forci= ng a connection drop if it is not available. LI is not the only reason why middleboxes are used, and certainly not the m= ain reason for CEMA. If one wants to do LI, it will be done with or without= CEMA :) The main reasons for CEMA are related to actions and procedures that take p= lace for every (or, at least a major part) of calls, where having to enable= B2BUA for every call will cause huge resource impact (see more below). Having said that, if needed we can add more text and guidance regarding the= usage of TLS. >The second puzzle brings me back to the question of what we are trying to = accomplish. This draft mandates the middlebox must be able to perform as a = B2BUA. That tells me such a middlebox will have the thousands of lines of c= ode required to implement a B2BUA. =20 >Moreover, the middlebox will have a few thousand lines of code to implemen= t the draft behavior. Given the relationship between code complexity and l= atent defects, I would expect the Security Considerations section to point = out that implementing this draft, in addition to=20 >the B2BUA functionality, which the network element must implement anyway, = reduces the practical security of the device, any networks it is supposed t= o protect, and Internet stability in general. As I've said before, the main issue is not (at least not from my own experi= ence with vendors and customers) the code it takes to implement B2BUA funct= ionality - it is the resource consumption when having to enable it. CEMA he= lps, as middleboxes now do not have to enable B2BUA in all cases, at that h= as lead (again, from my own experience) to major increase of interest in su= pporting MSRP.=20 For the non-B2BUA behavior, very little new code will be required for the m= iddlebox, since it will modify the SDP c/m line in the same way as it alrea= dy does for other media types. Regards, Christer On Jul 11, 2011, at 3:22 PM, Christer Holmberg wrote: > Hi, > > If I understand Eric's comments, they are not technical, so I *assume* th= ere is not much difference between -13 and earlier versions from that persp= ective. > > However, Eric does seem to imply that we could cover this by adding some = text to the applicability statement. > > Regards, > > Christer > > ________________________________________ > From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Ben = Campbell [ben@estacado.net] > Sent: Monday, July 11, 2011 11:10 PM > To: Simple WG > Cc: Eric Burger > Subject: Re: [Simple] External Review of draft-ietf-simple-msrp-sessmatch= -11 > > (as chair) > > Would anyone care to respond to Eric's review? These are not comments we = can easily ignore. Do the changes in version 13 make a difference here? > > Thanks! > > Ben. > > > On Jul 1, 2011, at 5:33 PM, Eric Burger wrote: > >> I was asked by the SIMPLE Work Group Chair to review the Internet Draft,= Session Matching Update for the Message Session Relay Protocol (MSRP). >> >> This document describes the behavior of a half-way kind of new network e= lement, the half-application layer gateway (ALG). I call this a half-ALG b= ecause a real ALG, in the SIP world, is a back-to-back user agent, or B2BUA= . >> >> In short, this draft is an advertisement for XMPP. The draft proposes a= quasi-but-not-at-all end-to-end protocol to enable middle boxes to relay a= n MSRP stream by hacking the signaling to the point there really is a new s= ession. In fact, there is a new session, but the draft is proposing a sess= ion to correlate the first session on one side of the half-ALG with the oth= er side. I would offer the applicability statement, saying that this draft = addresses the situation where there is deliberate network impairment and pa= rtition, due to the presence of these half-ALGs, immediately indicates that= we are not talking about an Internet topology, but some proprietary topolo= gy that happens to use the IP for transport. >> >> I suppose this extension would be acceptable if the half-ALG is required= to cryptographically identify itself and either end point can opt out. How= ever, if opting out means no message goes through, then by definition we ar= e not in the Internet, and such an extension would be out of scope for the = IETF. >> >> There are a host of nits, like the document's abbreviation being MSRP an= d bizarre formatting of section 7.1, but given the issues above, are true n= its._______________________________________________ >> 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 ibc@aliax.net Wed Jul 13 06:18: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 B0DED11E80C6 for ; Wed, 13 Jul 2011 06:18:25 -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 a4hIahaE96G2 for ; Wed, 13 Jul 2011 06:18:25 -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 24E9111E80B7 for ; Wed, 13 Jul 2011 06:18:25 -0700 (PDT) Received: by qyk29 with SMTP id 29so3920290qyk.10 for ; Wed, 13 Jul 2011 06:18:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.222 with SMTP id o30mr913077qci.189.1310563102475; Wed, 13 Jul 2011 06:18:22 -0700 (PDT) Received: by 10.229.185.195 with HTTP; Wed, 13 Jul 2011 06:18:22 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FD4@ESESSCMS0356.eemea.ericsson.se> References: <3DB36E28-7ED1-434F-BCC3-72FCDC94397A@standardstrack.com> <3D0F78C1-BADF-4407-8AFE-483CBEF3969B@estacado.net> <7F2072F1E0DE894DA4B517B93C6A05851DB6190FC8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05851DB6190FD4@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 13 Jul 2011 15:18:22 +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] External Review 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, 13 Jul 2011 13:18:25 -0000 2011/7/12 Christer Holmberg : > For the non-B2BUA behavior, very little new code will be required for the= middlebox, since it will modify the SDP c/m line in the same way as it alr= eady does for other media types. This is the first spec allowing an intermediary node to modify an SDP, am I right? well, if the middelbox acts as a real/full SIP B2BUA (UAS+UAC) then it's perfectly valid for it to reuse, modify or re-create the SDP. AFAIR the current spec mandates the middlebox to be a real/full SIP B2BUA; am I right? --=20 I=C3=B1aki Baz Castillo From zhengyli@cisco.com Sun Jul 17 02:07: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 22D0C21F869D for ; Sun, 17 Jul 2011 02:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.785 X-Spam-Level: X-Spam-Status: No, score=-8.785 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 Bt15yjpWtnZN for ; Sun, 17 Jul 2011 02:07:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 33B5821F869C for ; Sun, 17 Jul 2011 02:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=1391; q=dns/txt; s=iport; t=1310893630; x=1312103230; h=date:subject:from:to:message-id:mime-version; bh=aqjQv1jaVWHm3b/eHfhqrF9wbjGqW+InAAWJG61XKO0=; b=JpBZas1EcWBCEqTk2c5AC67ZkWH6k1e6LmyJs9KrEqJ5ua0slxJr/Ym2 JRp5zFoDKcHDWTiv5Fkn78W9YL1pWhyllzijqdwhLJwJ49MrLALT41c82 f2atQWpZ/d7hyI8rVl0kbBQvTEVGxQaum+l9n5NF0sDZnGyPY4tvkNh4z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUGAF2lIk5Io8UR/2dsb2JhbABSglOWI44UbHerboEjnRWGPASHUosUhQGLYQ X-IronPort-AV: E=Sophos;i="4.67,217,1309737600"; d="scan'208,217";a="102746064" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2011 09:07:05 +0000 Received: from [10.79.127.42] ([10.79.127.42]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6H974hV030641 for ; Sun, 17 Jul 2011 09:07:04 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 17 Jul 2011 17:07:01 +0800 From: Rockson Li To: Message-ID: Thread-Topic: On draft-ietf-simple-msrp-sessmatch-13 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393767224_374210" X-Mailman-Approved-At: Sun, 17 Jul 2011 07:54:21 -0700 Subject: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 17 Jul 2011 09:07:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393767224_374210 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello experts, I am wondering why the previous session-id only based session match update to RFC4975 was removed? It looks like our current assumption is the middle box would only change the c/m line in SDP. Why we have such assumption? Why we does not cover middle box changing a=path case? Thanks Regards, -Rockson --B_3393767224_374210 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello experts,
I am wondering why the previous session-id only based session ma= tch update to RFC4975 was removed?
It looks like our current assum= ption is the middle box would only change the c/m line in SDP.
Why= we have such assumption? Why  we does not cover middle box changing a=3D= path case?

Thanks
Regards,
-Roc= kson
--B_3393767224_374210-- From ben@nostrum.com Sun Jul 17 07:59: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 523E421F87C3 for ; Sun, 17 Jul 2011 07:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, 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 1z3eGJ-75Xle for ; Sun, 17 Jul 2011 07:59:03 -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 4DB4E21F8793 for ; Sun, 17 Jul 2011 07:59:03 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6HEwxGq008960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 17 Jul 2011 09:59:00 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--252425697 From: Ben Campbell In-Reply-To: Date: Sun, 17 Jul 2011 09:58:59 -0500 Message-Id: <2F794C7D-0B4E-40F3-8921-09FCFCD29B49@nostrum.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 17 Jul 2011 14:59:04 -0000 --Apple-Mail-1--252425697 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii (as chair) Hi Rockson, This change was the result of controversy over the security aspects of = changing the path attribute. We held a consensus call on the work group = list recently, and found rough consensus supporting the change. Do you = have a technical concern with that consensus? Thanks! Ben. On Jul 17, 2011, at 4:07 AM, Rockson Li wrote: > Hello experts, >=20 > I am wondering why the previous session-id only based session match = update to RFC4975 was removed? > It looks like our current assumption is the middle box would only = change the c/m line in SDP. > Why we have such assumption? Why we does not cover middle box = changing a=3Dpath case? >=20 > Thanks > Regards, > -Rockson > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-1--252425697 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hello = experts,

I am wondering why the previous = session-id only based session match update to RFC4975 was = removed?
It looks like our current assumption is the middle = box would only change the c/m line in SDP.
Why we have such = assumption? Why  we does not cover middle box changing a=3Dpath = case?

Thanks
Regards,
-Rockso= n
_______________________________________________
Simple mailing = list
Simple@ietf.org
https://www.ietf.or= g/mailman/listinfo/simple

= --Apple-Mail-1--252425697-- From ibc@aliax.net Sun Jul 17 08:04: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 9FB3521F89C1 for ; Sun, 17 Jul 2011 08:04:24 -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_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 3KEz-3MtHsXl for ; Sun, 17 Jul 2011 08:04: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 218CC21F89A7 for ; Sun, 17 Jul 2011 08:04:24 -0700 (PDT) Received: by qwc23 with SMTP id 23so1965901qwc.31 for ; Sun, 17 Jul 2011 08:04:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.36 with SMTP id y36mr4083396qce.227.1310915063495; Sun, 17 Jul 2011 08:04:23 -0700 (PDT) Received: by 10.229.185.195 with HTTP; Sun, 17 Jul 2011 08:04:23 -0700 (PDT) In-Reply-To: References: Date: Sun, 17 Jul 2011 17:04:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Rockson Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 17 Jul 2011 15:04:24 -0000 2011/7/17 Rockson Li : > I am wondering why the previous session-id only based session match updat= e > to RFC4975 was removed? > It looks like our current assumption is the middle box would only change = the > c/m line in SDP. > Why we have such assumption? Why =C2=A0we does not cover middle box chang= ing > a=3Dpath case? Basically because the previous behavior breaks the MSRP protocol just to allow middleboxes to intercept MSRP traffic without becoming real MSRP intermediaries, breaking compatibility with MSRP clients not aware of sessmatch. Anyhow I encourage you to check the recent archives of this maillist about this topic. --=20 I=C3=B1aki Baz Castillo From zhengyli@cisco.com Sun Jul 17 19:29: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 75C7D21F886C for ; Sun, 17 Jul 2011 19:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.976 X-Spam-Level: X-Spam-Status: No, score=-8.976 tagged_above=-999 required=5 tests=[AWL=-0.373, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] 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 HHTuFBQs5Gtl for ; Sun, 17 Jul 2011 19:29:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 15C7721F87E2 for ; Sun, 17 Jul 2011 19:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=6654; q=dns/txt; s=iport; t=1310956152; x=1312165752; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=F3hwtyrU0ylLpyCqxzcozM25P/B7Kw29UTPEgf4hp6Q=; b=HjaKcZr6hrDkC/EWlM3OAOYtKd3J1fdqv2/Hi0tAhxvDfi6XBdKjIE5d WoUnMqb0GR+H2mS0mZi81hNwap/agME+SK3VW5NLiOhDDEehdVTKUrL+7 Yw1FzGCYTJ5D3QNDrGYFMeEEMlgmoBsJnqy81eLBszdiXrMjLG67Ce1kn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEWaI05Io8UT/2dsb2JhbABSglOkL2x3iHykbZ0HhjwEh1KLFIUBi2E X-IronPort-AV: E=Sophos;i="4.67,219,1309737600"; d="scan'208,217";a="102792844" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2011 02:29:10 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6I2T7Zi021516; Mon, 18 Jul 2011 02:29:08 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 10:29:06 +0800 From: Rockson Li To: Ben Campbell Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: <2F794C7D-0B4E-40F3-8921-09FCFCD29B49@nostrum.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3393829749_221006" Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 02:29:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3393829749_221006 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hello Ben, Thanks for your kind reply. I have strong concern over this approach on SBC/ALG support for MSRP. I think most of SBC/ALG would not support B2BUA MSRP, which is too heavy in terms of implementation. And normally SBC/ALG are used together with NAT traversal and SBC/ALG has a very important feature topology hiding, which they are supposed to not expose one side internal topology to the other. Therefore when they are used for MSRP, they would behave as a SIP B2BUA changing c/m line and add its own a=path line for topology hiding , but a TCP NAT for MSRP by exchanging IP packets between the bridged networks. If we have session-id only based MSRP session algorithm, when SBC/ALG populate its own a=path, the only thing it need to do is replace the host addr of top uri in a=path retaining the session-id and block the other URIs in path if any. Without session-id only based session match, it's extremely difficult for SBC/ALG to behave as transparent MSRP forwarder while protecting those sensitive network specific information. Thanks Regards, -Rockson From: Ben Campbell Date: Sun, 17 Jul 2011 09:58:59 -0500 To: Rockson Li Cc: Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 (as chair) Hi Rockson, This change was the result of controversy over the security aspects of changing the path attribute. We held a consensus call on the work group list recently, and found rough consensus supporting the change. Do you have a technical concern with that consensus? Thanks! Ben. On Jul 17, 2011, at 4:07 AM, Rockson Li wrote: > Hello experts, > > I am wondering why the previous session-id only based session match update to > RFC4975 was removed? > It looks like our current assumption is the middle box would only change the > c/m line in SDP. > Why we have such assumption? Why we does not cover middle box changing a=path > case? > > Thanks > Regards, > -Rockson > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --B_3393829749_221006 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Hello Ben,

Thanks for your kind reply.

I have strong c= oncern over this approach on SBC/ALG support for MSRP.
I think mos= t of SBC/ALG would not support B2BUA MSRP, which is too heavy in terms of im= plementation.
And normally SBC/ALG  are used togeth= er with NAT traversal and SBC/ALG has a very important feature topology hidi= ng, which they are supposed to not expose one side internal topology to the = other.

Therefore when they are used for MSRP, they = would behave as a SIP B2BUA changing c/m line and add its own a=3Dpath line &n= bsp;for topology hiding , but a TCP NAT for MSRP by exchanging IP packets be= tween the bridged networks.
If we have session-id only based MSRP = session algorithm, when SBC/ALG populate its own a=3Dpath, the only thing it n= eed to do is replace the host addr of top uri in a=3Dpath retaining the sessio= n-id and block the other URIs in path if any.

Witho= ut session-id only based session match, it's extremely difficult for SBC/ALG= to behave  as transparent MSRP forwarder while protecting those sensit= ive network specific information.

Thanks
= Regards,
-Rockson

= From: Ben Campbell <ben@nostrum.= com>
Date: Sun, 17 Jul 2011= 09:58:59 -0500
To: Rockson Li <= ;zhengyli@cisco.com>
Cc: <simpl= e@ietf.org>
Subject: Re: [S= imple] On draft-ietf-simple-msrp-sessmatch-13

<= div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-bre= ak: after-white-space; ">
(as chair)

Hi Rockson,
This change was the result of controversy over the security = aspects of changing the path attribute. We held a consensus call on the work= group list recently, and found rough consensus supporting the change. Do yo= u have a technical concern with that consensus?

Tha= nks!

Ben.

On Jul 17, 2011, = at 4:07 AM, Rockson Li wrote:

Hello experts,
I am wondering why the previous session-id only based session ma= tch update to RFC4975 was removed?
It looks like our current assum= ption is the middle box would only change the c/m line in SDP.
Why= we have such assumption? Why  we does not cover middle box changing a=3D= path case?

Thanks
Regards,
-Roc= kson
_______________________________________________
Simple mailing list
<= a href=3D"mailto:Simple@ietf.org">Simple@ietf.org
https://www.ietf.org/mailman/listinfo/simp= le

--B_3393829749_221006-- From saul@ag-projects.com Sun Jul 17 23:53: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 2793821F8AD9 for ; Sun, 17 Jul 2011 23:53:03 -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 XKOasUq0dufc for ; Sun, 17 Jul 2011 23:53:02 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 93EFE21F8ABD for ; Sun, 17 Jul 2011 23:53:01 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 4E17BB01B1; Mon, 18 Jul 2011 08:52:58 +0200 (CEST) Received: from [192.168.1.36] (201.Red-83-43-229.dynamicIP.rima-tde.net [83.43.229.201]) by mail.sipthor.net (Postfix) with ESMTPSA id C2C6DB017D; Mon, 18 Jul 2011 08:52:44 +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: Mon, 18 Jul 2011 08:52:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 06:53:03 -0000 Hi Rockson, On Jul 18, 2011, at 4:29 AM, Rockson Li wrote: > Hello Ben, >=20 > Thanks for your kind reply. >=20 > I have strong concern over this approach on SBC/ALG support for MSRP. > I think most of SBC/ALG would not support B2BUA MSRP, which is too = heavy in terms of implementation. > And normally SBC/ALG are used together with NAT traversal and SBC/ALG = has a very important feature topology hiding, which they are supposed to = not expose one side internal topology to the other. >=20 Somebody (sorry, I don't recall who) mentioned this before: with the = current CEMA approach the a=3Dpath line remains unchanged, thus 100% = topology hiding is not possible. > Therefore when they are used for MSRP, they would behave as a SIP = B2BUA changing c/m line and add its own a=3Dpath line for topology = hiding , but a TCP NAT for MSRP by exchanging IP packets between the = bridged networks. > If we have session-id only based MSRP session algorithm, when SBC/ALG = populate its own a=3Dpath, the only thing it need to do is replace the = host addr of top uri in a=3Dpath retaining the session-id and block the = other URIs in path if any. >=20 > Without session-id only based session match, it's extremely difficult = for SBC/ALG to behave as transparent MSRP forwarder while protecting = those sensitive network specific information. >=20 Well, there is a huge problem with that approach: it just doesn't work = with standard (4975 and 4976) MSRP. And it also has security issues. = After a quite long discussion it was dumped in favor of the current one = and IMHO is very close to what SBC manufacturers want and doesn't break = standard MSRP. Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From zhengyli@cisco.com Mon Jul 18 00:05: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 6251821F8B2E for ; Mon, 18 Jul 2011 00:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.927 X-Spam-Level: X-Spam-Status: No, score=-9.927 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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-Tk3F9GlcTx for ; Mon, 18 Jul 2011 00:05:38 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 14A0121F8B27 for ; Mon, 18 Jul 2011 00:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=705; q=dns/txt; s=iport; t=1310972738; x=1312182338; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=qS3F6djiLxmsd151hQTU5xhuTsJAqR+OSrLp4RLSVKY=; b=M4tAZ2kR1XuI6gVl8qDW0XAnBIM6BnxhtuaNgjqUI4OMJPttXTpHpqwd xyc/lIRUFcMNf+001TfKWW9heDFAZCY9Y15UrsDjtoYhYHofRSVUYDuYN WW0HkVzjYni8CsNdXRUqSCjci57+XuGcoHm959b1j0YKpKucW4aaxUJIf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABDaI05Io8UR/2dsb2JhbABTp253iHylRJ0qhjwEh1KLFIUBi2E X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="42937122" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 07:05:35 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6I75Wp8011265; Mon, 18 Jul 2011 07:05:34 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 15:05:32 +0800 From: Rockson Li To: Saul Ibarra Corretge Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 07:05:42 -0000 Hello Saul, On 7/18/11 2:52 PM, "Saul Ibarra Corretge" wrote: >Well, there is a huge problem with that approach: it just doesn't work >with standard (4975 and 4976) MSRP. [RL]That's the reason why we need this update to update RFC4975. > >And it also has security issues. [RL] What are those security issues? Can you please elaborate? > After a quite long discussion it was dumped in favor of the current one >and IMHO is very close to what SBC manufacturers want and doesn't break >standard MSRP. [RL] I don't think SBC/ALG vendors would like to be full MSRP B2BUA. IMHO, transparent MSRP forwarder is what they are asking for, as one important alternative. From saul@ag-projects.com Mon Jul 18 00:21: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 75A7D21F8B42 for ; Mon, 18 Jul 2011 00:21:07 -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] 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 pncI4gMS4iy8 for ; Mon, 18 Jul 2011 00:21:07 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D4FD021F8B3F for ; Mon, 18 Jul 2011 00:21:06 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 66D66B01B1; Mon, 18 Jul 2011 09:21:05 +0200 (CEST) Received: from [192.168.1.36] (201.Red-83-43-229.dynamicIP.rima-tde.net [83.43.229.201]) by mail.sipthor.net (Postfix) with ESMTPSA id C529EB0181; Mon, 18 Jul 2011 09:21:02 +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: Mon, 18 Jul 2011 09:21:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36E242DC-EF4F-402E-A711-B9208EFA84F3@ag-projects.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 07:21:07 -0000 Hi, On Jul 18, 2011, at 9:05 AM, Rockson Li wrote: > Hello Saul, >=20 > On 7/18/11 2:52 PM, "Saul Ibarra Corretge" = wrote: >=20 >> Well, there is a huge problem with that approach: it just doesn't = work >> with standard (4975 and 4976) MSRP. > [RL]That's the reason why we need this update to update RFC4975. I don't think so, because this mechanism is not needed on the Internet. = It is only needed by vendors wanting to anchor all media. The protocol = works just fine with MSRP relays or ACM as NAT traversal solutions, the = only reason for this draft to exist is that SBC manufacturers want a = 'cheap' (a B2BUA may have some performance issues according to them) = mechanism to intercept MSRP. >=20 >> And it also has security issues. > [RL] What are those security issues? Can you please elaborate? >=20 Basically TLS name based authentication is broken. >> After a quite long discussion it was dumped in favor of the current = one >> and IMHO is very close to what SBC manufacturers want and doesn't = break >> standard MSRP. > [RL] I don't think SBC/ALG vendors would like to be full MSRP B2BUA. = IMHO, > transparent MSRP forwarder is what they are asking for, as one = important > alternative. >=20 This last approach, CEMA, only uses the B2BUA functionality in cases = where nothing else can be done. If all endpoints are CEMA-aware, no = B2BUA will be used, but we need to guarantee that interoperability with = non-CEMA endpoints will be maintained. Its unacceptable that a protocol = is broken just for enhancing the performance of an SBC who wants to = intercepting MSRP media. --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From zhengyli@cisco.com Mon Jul 18 00:57: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 334A421F8B74 for ; Mon, 18 Jul 2011 00:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.002 X-Spam-Level: X-Spam-Status: No, score=-10.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 UfTPt70owJpD for ; Mon, 18 Jul 2011 00:57:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id D460121F8B6F for ; Mon, 18 Jul 2011 00:57:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=1997; q=dns/txt; s=iport; t=1310975872; x=1312185472; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=6G/ddwcJPepLhdCghPrXVdKXwO8P/0c2S1Qa67bLqvA=; b=kC93TRRK4iUGkGIuwjnFphyhHkkdGMamMrG0DoHk31HO/pgtV7917Bte 1O6DvY6AQVSoyYyLAL+KcAmAlf0ammCmgzGZtCKFL6TMWq4SUmJEpYKRg /ebwDWcODhvjlhEoAyF29rCfaYNUFZnuit6Zw2sVZFpcwa34sHOdio79N c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHfmI05Io8UR/2dsb2JhbABTp213rhudRYY8BIclLYsUhQGLYQ X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="102839088" Received: from bgl-core-2.cisco.com ([72.163.197.17]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2011 07:57:49 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6I7vliH020068; Mon, 18 Jul 2011 07:57:48 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 15:57:46 +0800 From: Rockson Li To: Saul Ibarra Corretge Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: <36E242DC-EF4F-402E-A711-B9208EFA84F3@ag-projects.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 07:57:56 -0000 Saul, Thanks for your reply. Please check my comments inline. -Rockson On 7/18/11 3:21 PM, "Saul Ibarra Corretge" wrote: >Hi, > >On Jul 18, 2011, at 9:05 AM, Rockson Li wrote: > >I don't think so, because this mechanism is not needed on the Internet. >It is only needed by vendors wanting to anchor all media. The protocol >works just fine with MSRP relays or ACM as NAT traversal solutions, the >only reason for this draft to exist is that SBC manufacturers want a >'cheap' (a B2BUA may have some performance issues according to them) >mechanism to intercept MSRP. If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for this mechanism in Internet. Remember most of the SIP NAT/ALG, regardless your preference, the only thing they do is mapping the IP addr in the IP/SIP/SDP payload, I don't think they would ever function as a MSRP B2BUA. >>=20 > >Basically TLS name based authentication is broken. I don't understand why TLS ed authentication is broken here. Weather IP addr in path uri or c line are used for TLS connection, it's a matter of TLS client.How does TLS server should know where client get the ip addr and why does it need care about it? >>=20 > >This last approach, CEMA, only uses the B2BUA functionality in cases >where nothing else can be done. If all endpoints are CEMA-aware, no B2BUA >will be used, but we need to guarantee that interoperability with >non-CEMA endpoints will be maintained. Its unacceptable that a protocol >is broken just for enhancing the performance of an SBC who wants to >intercepting MSRP media. I don't want to break the spec, this might be added as an extension. If we find something undesirable in real world use case, why we cannot come up with some solution to it? If simple WG does not come up with a standard workaround, numerous propriety solution will definitely show up eventually. >--=20 >Sa=FAl Ibarra Corretg=E9 >AG Projects > > > > > From saul@ag-projects.com Mon Jul 18 01:14: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 D2BD921F8B78 for ; Mon, 18 Jul 2011 01:14:30 -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, 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 5N-GeExBQIuW for ; Mon, 18 Jul 2011 01:14:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E953A21F8B5F for ; Mon, 18 Jul 2011 01:14:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B7639B01B7; Mon, 18 Jul 2011 10:14:28 +0200 (CEST) Received: from [192.168.1.36] (201.Red-83-43-229.dynamicIP.rima-tde.net [83.43.229.201]) by mail.sipthor.net (Postfix) with ESMTPSA id 6F5D2B0181; Mon, 18 Jul 2011 10:14:27 +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: Mon, 18 Jul 2011 10:14:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E6A508B-1119-4C9C-98A8-84D69B60044B@ag-projects.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 08:14:30 -0000 Hi, >>=20 >> I don't think so, because this mechanism is not needed on the = Internet. >> It is only needed by vendors wanting to anchor all media. The = protocol >> works just fine with MSRP relays or ACM as NAT traversal solutions, = the >> only reason for this draft to exist is that SBC manufacturers want a >> 'cheap' (a B2BUA may have some performance issues according to them) >> mechanism to intercept MSRP. >=20 > If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for > this mechanism in Internet. > Remember most of the SIP NAT/ALG, regardless your preference, the only > thing they do is mapping the IP addr in the IP/SIP/SDP payload, > I don't think they would ever function as a MSRP B2BUA. >=20 We are talking about SBC-like middleboxes here, not cheap home routers. = Now, it these middleboxes want to claim they support MSRP media = anchoring, they will need to implement the B2BUA (which is not used on = every case), that's what is specified in draft 13 right now. >>=20 >> Basically TLS name based authentication is broken. >=20 > I don't understand why TLS ed authentication is broken here. Weather = IP > addr in path uri or c line are used for TLS connection, > it's a matter of TLS client.How does TLS server should know where = client > get the ip addr and why does it need care about it? How can I verify who the other end is if the element that identifies = that (a=3Dpath line) gets mangled by someone in between? With the = 'sessmatch' approach the SBC would hack the SDP to fool the endpoints so = that they connect to the SBC instead of connecting to the other end, so = they can't verify the other end. >>>=20 >>=20 >> This last approach, CEMA, only uses the B2BUA functionality in cases >> where nothing else can be done. If all endpoints are CEMA-aware, no = B2BUA >> will be used, but we need to guarantee that interoperability with >> non-CEMA endpoints will be maintained. Its unacceptable that a = protocol >> is broken just for enhancing the performance of an SBC who wants to >> intercepting MSRP media. >=20 > I don't want to break the spec, this might be added as an extension. The current approach (CEMA) works in all possible scenarios. What don't = you like about it? The fact that a B2BUA is needed in some corner cases = for the sake of interoperability? > If we find something undesirable in real world use case, why we cannot > come up with some solution to it? Undesirable for whom? I personally have no problem at all with the = current MSRP related specs. *This* spec is trying to solve a problem = caused by the people who like to be in the middle of things. The proper = way of anchoring MSRP media is to implement a B2BUA. Period. People = started to implement the a=3Dpath line hack and this spec tries to = justify it. We finally came to an agreement on how to make both sides = happy: CEMA, and I would strongly object going back to sessmatch. > If simple WG does not come up with a standard workaround, numerous > propriety solution will definitely show up eventually. They are already doing it, we are all trying to fix it here :-) --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Jul 18 01:41: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 9F65C21F86C1 for ; Mon, 18 Jul 2011 01:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.665 X-Spam-Level: X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=0.012, 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 bhX4GzpzfVh5 for ; Mon, 18 Jul 2011 01:41:09 -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 5B5F021F8B6F for ; Mon, 18 Jul 2011 01:41:09 -0700 (PDT) Received: by qyk29 with SMTP id 29so2233147qyk.10 for ; Mon, 18 Jul 2011 01:41:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.105.95 with SMTP id s31mr4528316qco.228.1310978468627; Mon, 18 Jul 2011 01:41:08 -0700 (PDT) Received: by 10.229.185.195 with HTTP; Mon, 18 Jul 2011 01:41:08 -0700 (PDT) In-Reply-To: References: <36E242DC-EF4F-402E-A711-B9208EFA84F3@ag-projects.com> Date: Mon, 18 Jul 2011 10:41:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Rockson Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 08:41:13 -0000 2011/7/18 Rockson Li : > If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for > this mechanism in Internet. RFC 4976 (MSRP Relays) achieves it. > Remember most of the SIP NAT/ALG, regardless your preference, the only > thing they do is mapping the IP addr in the IP/SIP/SDP payload, And they suck, do you agree? > I don't think they would ever function as a MSRP B2BUA. They *don't* work neither as a SIP NAT/ALG since in 99% of cases they break something: http://www.voip-info.org/wiki/view/Routers+SIP+ALG >>This last approach, CEMA, only uses the B2BUA functionality in cases >>where nothing else can be done. If all endpoints are CEMA-aware, no B2BUA >>will be used, but we need to guarantee that interoperability with >>non-CEMA endpoints will be maintained. Its unacceptable that a protocol >>is broken just for enhancing the performance of an SBC who wants to >>intercepting MSRP media. > > I don't want to break the spec, this might be added as an extension. An extension that will make today's MSRP clients not to work with CEMA/sessmatch middleboxes. An extensions just useful for wallen gardens (and not for real Internet). NOTE: I mean CEMA middleboxes not acting as a full MSRP B2BUA (as clearly you suggest). > If we find something undesirable in real world use case, why we cannot > come up with some solution to it? Because the problem you have has nothing to do with pure Internet (IETF is supposed to write specs for Internet) neither with an end to end protocol as SIP/MSRP. Instead you want to build a SIP island behind a SBC device (a wallen garden) and don't care that such SBC breaks current implementations of MSRP (already working in pure Internet). > If simple WG does not come up with a standard workaround, numerous > propriety solution will definitely show up eventually. Again I ask you to check the recent archives of this maillist as these topics have been heavily discussed and argued. Regards. --=20 I=C3=B1aki Baz Castillo From zhengyli@cisco.com Mon Jul 18 02: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 162AE21F8B88 for ; Mon, 18 Jul 2011 02:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.762 X-Spam-Level: X-Spam-Status: No, score=-9.762 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] 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 3INGGQ5Ifnz7 for ; Mon, 18 Jul 2011 02:28:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6D21F87BC for ; Mon, 18 Jul 2011 02:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=4625; q=dns/txt; s=iport; t=1310981306; x=1312190906; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Yqo/lZl38I9WFcm5D4ltERhVZnDznv9iHR/Kj76nvnw=; b=jTOeHBRzrY2kPnVwzsdQz6QyW2EUFMVkz/bHn9O0aWhEzbVMkcs2yTHk W7cnzV65doadTSbD0oHLfJmPaGv6yBlLGW/YqNgdeJYpbQtfU8phsk0+T IMhrJUQejV9L5pa4WiikGGv9wBG8NxEtIs5Rf4bQiu+JCylube6QB4mI4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMr7I05Io8UT/2dsb2JhbABHDYRJoyV3iHylb40WCJAygSeBfYIFgRMEh1KLFIUBi2E X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="42965779" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 09:28:24 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6I9SKKk008491; Mon, 18 Jul 2011 09:28:22 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 17:28:17 +0800 From: Rockson Li To: Saul Ibarra Corretge Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: <8E6A508B-1119-4C9C-98A8-84D69B60044B@ag-projects.com> Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 09:28:31 -0000 Saul=A3=AC On 7/18/11 4:14 PM, "Saul Ibarra Corretge" wrote: >Hi, > >>>=20 >>> I don't think so, because this mechanism is not needed on the Internet. >>> It is only needed by vendors wanting to anchor all media. The protocol >>> works just fine with MSRP relays or ACM as NAT traversal solutions, >>>the >>> only reason for this draft to exist is that SBC manufacturers want a >>> 'cheap' (a B2BUA may have some performance issues according to them) >>> mechanism to intercept MSRP. >>=20 >> If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for >> this mechanism in Internet. >> Remember most of the SIP NAT/ALG, regardless your preference, the only >> thing they do is mapping the IP addr in the IP/SIP/SDP payload, >> I don't think they would ever function as a MSRP B2BUA. >>=20 > >We are talking about SBC-like middleboxes here, not cheap home routers. >Now, it these middleboxes want to claim they support MSRP media >anchoring, they will need to implement the B2BUA (which is not used on >every case), that's what is specified in draft 13 right now. Please do remember MSRP is used for IM, which is used by end user who are connected to Internet with home router. If it cannot go through home router, I don't think MSRP would be successful at all. You are correct, home router is low cost, the investment of it need go to the area which deserves. It does not care what's inside the MSRP, why the MSRP spec force it to decode/encode TCP packets as a MSRP B2BUA? > >>>=20 >>> Basically TLS name based authentication is broken. >>=20 >> I don't understand why TLS ed authentication is broken here. Weather IP >> addr in path uri or c line are used for TLS connection, >> it's a matter of TLS client.How does TLS server should know where client >> get the ip addr and why does it need care about it? > >How can I verify who the other end is if the element that identifies that >(a=3Dpath line) gets mangled by someone in between? With the 'sessmatch' >approach the SBC would hack the SDP to fool the endpoints so that they >connect to the SBC instead of connecting to the other end, so they can't >verify the other end. Use IP addr to verify the identity does not make any sense. Imaging all the NAT device used today, all the IP addr are changed, would that be a security downgrade? Identity verification is done by certificate exchange and verification. Verify the root CA and the identity of the owner of the certificate you are talking to by looking at certificate's DistinguishedName is current TLS standard approach. Distinguished Name is human oriented, it does not make sense to make people to remember all the valid ip addr they are allowed to talk to. > >>>>=20 >>>=20 >>> This last approach, CEMA, only uses the B2BUA functionality in cases >>> where nothing else can be done. If all endpoints are CEMA-aware, no >>>B2BUA >>> will be used, but we need to guarantee that interoperability with >>> non-CEMA endpoints will be maintained. Its unacceptable that a protocol >>> is broken just for enhancing the performance of an SBC who wants to >>> intercepting MSRP media. >>=20 >> I don't want to break the spec, this might be added as an extension. > >The current approach (CEMA) works in all possible scenarios. What don't >you like about it? The fact that a B2BUA is needed in some corner cases >for the sake of interoperability? That's not corner case at all. MSRP B2BUA is costly for many low end device. I thought session-match is an agreed-on approach to allow many low end NAT/ALG device to transparently pass through MSRP , but suddenly it is removed :-( =20 > >> If we find something undesirable in real world use case, why we cannot >> come up with some solution to it? > >Undesirable for whom? To NAG/ALG/SBC vendor. >I personally have no problem at all with the current MSRP related specs. >*This* spec is trying to solve a problem caused by the people who like to >be in the middle of things. The proper way of anchoring MSRP media is to >implement a B2BUA. Period. People started to implement the a=3Dpath line >hack and this spec tries to justify it. We finally came to an agreement >on how to make both sides happy: CEMA, and I would strongly object going >back to sessmatch. > >> If simple WG does not come up with a standard workaround, numerous >> propriety solution will definitely show up eventually. > >They are already doing it, we are all trying to fix it here :-) > >--=20 >Sa=A8=B2l Ibarra Corretg=A8=A6 >AG Projects > > > > > From saul@ag-projects.com Mon Jul 18 02:39: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 4DF2121F8B3A for ; Mon, 18 Jul 2011 02:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.200, 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 P51ffH5ioxPJ for ; Mon, 18 Jul 2011 02:39:05 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9B27121F8B05 for ; Mon, 18 Jul 2011 02:39:05 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B0943B01B7; Mon, 18 Jul 2011 11:39:04 +0200 (CEST) Received: from [192.168.1.42] (201.Red-83-43-229.dynamicIP.rima-tde.net [83.43.229.201]) by mail.sipthor.net (Postfix) with ESMTPSA id A783BB017D; Mon, 18 Jul 2011 11:39:03 +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: Mon, 18 Jul 2011 11:39:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0CACFB-D349-46E8-B203-24E2BBE2ECBC@ag-projects.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 09:39:06 -0000 Rockson, >=20 > Please do remember MSRP is used for IM, which is used by end user who = are > connected to Internet with home router. > If it cannot go through home router, I don't think MSRP would be > successful at all. > You are correct, home router is low cost, the investment of it need go = to > the area which deserves. > It does not care what's inside the MSRP, why the MSRP spec force it to > decode/encode TCP packets as a MSRP B2BUA? >=20 Please, go through the previous emails in the list, this spec is *not* = targeted at low-end devices, but to middleboxes wanting to anchor MSRP = media for whatever reason. A home router shouldn't touch MSRP at all. >=20 > Use IP addr to verify the identity does not make any sense. > Imaging all the NAT device used today, all the IP addr are changed, = would > that be a security downgrade? > Identity verification is done by certificate exchange and = verification. > Verify the root CA and the identity of the owner of the certificate = you > are talking to by looking at certificate's DistinguishedName > is current TLS standard approach. > Distinguished Name is human oriented, it does not make sense to make > people to remember all the valid ip addr they are allowed to talk to. I may not recall correctly, maybe someone else does, but this was an = important reason for dumping the sessmatch approach. >=20 > That's not corner case at all. Read draft 13. It is. If all devices implement CEMA no B2BUA is needed. = It would only be needed for interoperating with non-CEMA endpoints or = when relays are being used. > MSRP B2BUA is costly for many low end device. As I said before, this spec is not targeted at low end devices. > I thought session-match is an agreed-on approach to allow many low end > NAT/ALG device to transparently pass through MSRP , but suddenly it is > removed :-( >=20 For good reasons :-) --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Jul 18 02: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 BBADA21F8B4A for ; Mon, 18 Jul 2011 02:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=0.011, 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 5ojbGgZrjY8v for ; Mon, 18 Jul 2011 02:43:39 -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 337F221F8B48 for ; Mon, 18 Jul 2011 02:43:39 -0700 (PDT) Received: by qyk9 with SMTP id 9so1867902qyk.10 for ; Mon, 18 Jul 2011 02:43:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.36 with SMTP id y36mr4609660qce.227.1310982218469; Mon, 18 Jul 2011 02:43:38 -0700 (PDT) Received: by 10.229.185.195 with HTTP; Mon, 18 Jul 2011 02:43:38 -0700 (PDT) In-Reply-To: References: <8E6A508B-1119-4C9C-98A8-84D69B60044B@ag-projects.com> Date: Mon, 18 Jul 2011 11:43:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Rockson Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 09:43:39 -0000 2011/7/18 Rockson Li : >>We are talking about SBC-like middleboxes here, not cheap home routers. >>Now, it these middleboxes want to claim they support MSRP media >>anchoring, they will need to implement the B2BUA (which is not used on >>every case), that's what is specified in draft 13 right now. > > Please do remember MSRP is used for IM, which is used by end user who are > connected to Internet with home router. > If it cannot go through home router, I don't think MSRP would be > successful at all. A home router should not "play" with SIP neither with MSRP. The service provider should/could use server side solutions (as MSRP relays) and it's done. But I don't understand your point: are you in favor of implementing MSRP ALG in home routers in the same way they poorly implement SIP ALG (breaking SIP *always*) ? --=20 I=C3=B1aki Baz Castillo From zhengyli@cisco.com Mon Jul 18 02:54: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 D564C21F8B74 for ; Mon, 18 Jul 2011 02:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.783 X-Spam-Level: X-Spam-Status: No, score=-9.783 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8] 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 beakJIplWIgL for ; Mon, 18 Jul 2011 02:54:45 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1E221F8B73 for ; Mon, 18 Jul 2011 02:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=2220; q=dns/txt; s=iport; t=1310982885; x=1312192485; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=MCpOJBHCJTR3RD6O1f84To5OkB2LttA4P310qnkTeCw=; b=SSPZOGMXW6ST3RPvdAw/egyX1q+liJaXPl4+WwxTz8WzzSpE8yRSYDC3 7U5MjppJd4TbOeaDvooYTaReDl7UE+1LBlBerpiQVG2/fZOo1CpRekbNH lD0HrY0hULI6l/rk30vW4V/Ec8MSi3fpnCBSrkIyoGpT3jriD9yJeMj01 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKYBJE5Io8UT/2dsb2JhbABHDadud651nVSDJIMYBIclLYsUhQGLYQ X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="42971595" Received: from bgl-core-4.cisco.com ([72.163.197.19]) by ams-iport-2.cisco.com with ESMTP; 18 Jul 2011 09:54:43 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6I9sdxE013680; Mon, 18 Jul 2011 09:54:42 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 17:54:37 +0800 From: Rockson Li To: Saul Ibarra Corretge Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: <2E0CACFB-D349-46E8-B203-24E2BBE2ECBC@ag-projects.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 09:54:49 -0000 Saul, On 7/18/11 5:39 PM, "Saul Ibarra Corretge" wrote: >Please, go through the previous emails in the list, this spec is *not* >targeted at low-end devices, but to middleboxes wanting to anchor MSRP >media for whatever reason. A home router shouldn't touch MSRP at all. That is not home router wants to touch MSRP, the case is user using MSRP needs to connect themselves by home router to Internet, in which case, home router has to touch MSRP. > >>=20 >> Use IP addr to verify the identity does not make any sense. >> Imaging all the NAT device used today, all the IP addr are changed, >>would >> that be a security downgrade? >> Identity verification is done by certificate exchange and verification. >> Verify the root CA and the identity of the owner of the certificate you >> are talking to by looking at certificate's DistinguishedName >> is current TLS standard approach. >> Distinguished Name is human oriented, it does not make sense to make >> people to remember all the valid ip addr they are allowed to talk to. > >I may not recall correctly, maybe someone else does, but this was an >important reason for dumping the sessmatch approach. > >>=20 >> That's not corner case at all. > >Read draft 13. It is. If all devices implement CEMA no B2BUA is needed. >It would only be needed for interoperating with non-CEMA endpoints or >when relays are being used. As I said previously, home router would be like a SIP NAT/ALG, most of the devices would replace all the internal IP addr with public IP addr, regardless in SIP header or SDP attributes. Which means a=3Dpath would have to be changed, this is beyond your assumption of middle box's behavior. > >> MSRP B2BUA is costly for many low end device. > >As I said before, this spec is not targeted at low end devices. I don't understand why we cannot target at them, actually previous session-match already covers them. > >> I thought session-match is an agreed-on approach to allow many low end >> NAT/ALG device to transparently pass through MSRP , but suddenly it is >> removed :-( >>=20 > >For good reasons :-) > >--=20 >Sa=FAl Ibarra Corretg=E9 >AG Projects > > > > > From zhengyli@cisco.com Mon Jul 18 03:02: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 C2AB121F857E for ; Mon, 18 Jul 2011 03:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.651 X-Spam-Level: X-Spam-Status: No, score=-9.651 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] 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 Web8G0FPsjSe for ; Mon, 18 Jul 2011 03:02:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DC4E321F8515 for ; Mon, 18 Jul 2011 03:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=1569; q=dns/txt; s=iport; t=1310983323; x=1312192923; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=aRSNWWlVnCAuLcHbHJ9EHZGJylI7h/JPsKE3rJwwM0I=; b=QzgfiYtPz/ZScN5UIecgHnsEchedsBFThPjEln7yuaZmBlxdI9e7/RpU 6HzLDSi+DL5+u0gkbrstN2d2w0jKu+ntOWT8cZerpb9QneYXNBjUKbhpX 2+LYAwdhZgGvCj//5CCPevSxb60ZCHZayYR6MuQ2fHVVFkhT5K40U5jwd c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMADJE5Io8UQ/2dsb2JhbABUp253rj2dVYY8BIclLYsUhQGLYQ X-IronPort-AV: E=Sophos;i="4.67,221,1309737600"; d="scan'208";a="102868035" Received: from bgl-core-1.cisco.com ([72.163.197.16]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2011 10:02:00 +0000 Received: from [64.104.167.59] ([64.104.167.59]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p6IA1swX003195; Mon, 18 Jul 2011 10:01:57 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 18 Jul 2011 18:01:52 +0800 From: Rockson Li To: =?ISO-8859-1?B?SfFha2k=?= Baz Castillo Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 10:02:03 -0000 Home router is an example of SIP ALG. most of the devices would replace all the internal IP addr with public IP addr, regardless in SIP header or SDP attributes. Which means a=3Dpath would have to be changed, I am not in favor of implementing MSRP ALG, I just think if this draft needs cover middle box, SIP ALG needs be covered. Actually previous session-match approach already fixes this SIP ALG issue. Maybe we need figure out a way somehow to put session-match and CEMA together to cover all the types of middle boxes. Thanks -Rockson On 7/18/11 5:43 PM, "I=F1aki Baz Castillo" wrote: >2011/7/18 Rockson Li : >>>We are talking about SBC-like middleboxes here, not cheap home routers. >>>Now, it these middleboxes want to claim they support MSRP media >>>anchoring, they will need to implement the B2BUA (which is not used on >>>every case), that's what is specified in draft 13 right now. >> >> Please do remember MSRP is used for IM, which is used by end user who >>are >> connected to Internet with home router. >> If it cannot go through home router, I don't think MSRP would be >> successful at all. > >A home router should not "play" with SIP neither with MSRP. The >service provider should/could use server side solutions (as MSRP >relays) and it's done. > >But I don't understand your point: are you in favor of implementing >MSRP ALG in home routers in the same way they poorly implement SIP ALG >(breaking SIP *always*) ? > > >--=20 >I=F1aki Baz Castillo > From saul@ag-projects.com Mon Jul 18 03:02: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 B958221F8B8F for ; Mon, 18 Jul 2011 03:02:38 -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, 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 FD7M23jyd+fq for ; Mon, 18 Jul 2011 03:02:36 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40821F8515 for ; Mon, 18 Jul 2011 03:02:36 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C9076B01B8; Mon, 18 Jul 2011 12:02:33 +0200 (CEST) Received: from [192.168.1.42] (201.Red-83-43-229.dynamicIP.rima-tde.net [83.43.229.201]) by mail.sipthor.net (Postfix) with ESMTPSA id C85B0B017D; Mon, 18 Jul 2011 12:02:32 +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: Mon, 18 Jul 2011 12:02:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 10:02:38 -0000 Rockson, >=20 > That is not home router wants to touch MSRP, the case is user using = MSRP > needs to connect themselves by home router to Internet, in which case, > home router has to touch MSRP. There are mechanisms for that already: MSRP relays and also ACM, that is = not needed and is also bad because it breaks interoperability, as I said = before. >>=20 >> Read draft 13. It is. If all devices implement CEMA no B2BUA is = needed. >> It would only be needed for interoperating with non-CEMA endpoints or >> when relays are being used. > As I said previously, home router would be like a SIP NAT/ALG, most of = the > devices would replace all the internal IP addr with public IP addr, > regardless in SIP header or SDP attributes. > Which means a=3Dpath would have to be changed, this is beyond your > assumption of middle box's behavior. One wrong does not justify another. What you described is completely = wrong. I've seen many devices doing that, and in the process of trying = to fix I don't know what, they completely break other things such as = MSRP or even ICE. Replacing all private IP occurrences with the public = one is a checp hack nobody should do because it doesn't work. >>=20 >>> MSRP B2BUA is costly for many low end device. >>=20 >> As I said before, this spec is not targeted at low end devices. >=20 > I don't understand why we cannot target at them, actually previous > session-match already covers them. Because there is no need to do it. With the current approach if the = endpoints and the server support it everything will work. --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Jul 18 03:30: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 84BEE21F8BB9 for ; Mon, 18 Jul 2011 03:30:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=0.011, 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 LryM6FnoNIpg for ; Mon, 18 Jul 2011 03:30: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 4487021F8BB7 for ; Mon, 18 Jul 2011 03:30:09 -0700 (PDT) Received: by qwc23 with SMTP id 23so2450216qwc.31 for ; Mon, 18 Jul 2011 03:30:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.66.25 with SMTP id l25mr4633444qci.265.1310985008775; Mon, 18 Jul 2011 03:30:08 -0700 (PDT) Received: by 10.229.185.195 with HTTP; Mon, 18 Jul 2011 03:30:08 -0700 (PDT) In-Reply-To: References: Date: Mon, 18 Jul 2011 12:30:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Rockson Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: simple@ietf.org Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 10:30:13 -0000 2011/7/18 Rockson Li : > I am not in favor of implementing MSRP ALG, I just think if this draft > needs cover middle box, SIP ALG needs be covered. > Actually previous session-match approach already fixes this =C2=A0SIP ALG= issue. > Maybe we need figure out a way somehow to put session-match and CEMA > together to cover all the types of middle boxes. CEMA draft clearly states that the middlebox MUST be a *real* SIP node (a proxy or a B2BUA) which talks real SIP (rather than be a cheap home router which just applies a regular expression over the SIP message by breaking the signalling in 99% of cases). So, I insist: CEMA draft states that the middlebox can modify the SDP but it MUST be a real SIP node. Do you agree with this? or do you expect that this specification should also cover SIP ALG routers [*] (those that just mangle the SIP messages)? [*] http://www.voip-info.org/wiki/view/Routers+SIP+ALG Please clarify it. --=20 I=C3=B1aki Baz Castillo From prasun.bheri@gmail.com Mon Jul 18 07:16: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 8F78521F867F for ; Mon, 18 Jul 2011 07:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 aQ5XVYGhfICW for ; Mon, 18 Jul 2011 07:16:39 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id E630221F85AC for ; Mon, 18 Jul 2011 07:16:30 -0700 (PDT) Received: by yie30 with SMTP id 30so1501396yie.31 for ; Mon, 18 Jul 2011 07:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=MZWXNVQ/oi5q4q3Bpe4Vb3i7krYJc4+Rooi7XsgoOIg=; b=WygJqTB26HKZxB6d5X9vqurqjzgyvsDwCjLcit8qrTx5q/9Tvm8h6/N6vrVX7wtxZg tktc7b6J876iUKtXksq8+tGoVrfdHF6lkJzuG/ubQC8tab7XMvCLH8HT85jrpl7/BBHt zRdUX3KOWrna3/x/SKk3QaSK498Lhtbcze9N8= Received: by 10.236.197.38 with SMTP id s26mr8387185yhn.249.1310998590157; Mon, 18 Jul 2011 07:16:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.63.146 with HTTP; Mon, 18 Jul 2011 07:15:50 -0700 (PDT) From: prasun bheri Date: Mon, 18 Jul 2011 19:45:50 +0530 Message-ID: To: Simple@ietf.org Content-Type: multipart/alternative; boundary=20cf3040e37644745004a858a51c Subject: [Simple] Please clarify this ambiguity with terminology. 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, 18 Jul 2011 14:49:48 -0000 --20cf3040e37644745004a858a51c Content-Type: text/plain; charset=ISO-8859-1 Hello Group, I have a little ambiguity with terminology in rfc4975 in this document, section 7.3.2 (page 27), fourth paragraph, it reads "it is possible that an endpoint will receive a REPORT 'request' on a session that is no longer valid" in this context this REPORT (success/failure of a transaction) is being sent to a session that has expired. here REPORT is clearly sent as a 'response' where as in document it is referred as report 'request'. is there any specific reason to call it as report request rather than calling it as response? Thanks & Regards Prasun --20cf3040e37644745004a858a51c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Group,
I have a little ambiguity with terminology in rfc4975
<= div>
in this document, section 7.3.2 (page 27), fourth paragr= aph, it reads

"it is possible that an endpoin= t will receive a REPORT 'request' on a session that is no longer va= lid"=A0

in this context this REPORT (success/failure of a trans= action) is being sent to a session that has expired.=A0
her= e REPORT is clearly sent as a 'response' where as in document it is= =A0referred=A0as report 'request'.

is there any specific reason to call it as report reque= st rather than calling it as response?

Thanks &= ; Regards
Prasun

--20cf3040e37644745004a858a51c-- From ben@nostrum.com Mon Jul 18 08:07: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 86D9F21F8B82 for ; Mon, 18 Jul 2011 08:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, 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 2fQj+Qct9pix for ; Mon, 18 Jul 2011 08:07:55 -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 AF89321F8B12 for ; Mon, 18 Jul 2011 08:07:54 -0700 (PDT) Received: from [10.0.1.6] (cpe-76-187-75-59.tx.res.rr.com [76.187.75.59]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6IF7pl9040291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 10:07:51 -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: Date: Mon, 18 Jul 2011 10:07:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B36D94D-F74D-4ACA-9F8F-0C9A08EF76F3@nostrum.com> References: To: prasun bheri X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 76.187.75.59 is authenticated by a trusted mechanism) Cc: Simple@ietf.org Subject: Re: [Simple] Please clarify this ambiguity with terminology. 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, 18 Jul 2011 15:07:59 -0000 On Jul 18, 2011, at 9:15 AM, prasun bheri wrote: > Hello Group, > I have a little ambiguity with terminology in rfc4975 >=20 > in this document, section 7.3.2 (page 27), fourth paragraph, it reads >=20 > "it is possible that an endpoint will receive a REPORT 'request' on a = session that is no longer valid"=20 >=20 > in this context this REPORT (success/failure of a transaction) is = being sent to a session that has expired.=20 > here REPORT is clearly sent as a 'response' where as in document it is = referred as report 'request'. >=20 > is there any specific reason to call it as report request rather than = calling it as response? Yes. A REPORT request is different than a response. A response is a = transactional response to a specific request. a REPORT request is a way = to send delivery information to an upstream device. It may cover data = from more than one request. It has a different format, and is used in = different situations, than a "response". Hope this helps. Ben. >=20 > Thanks & Regards > Prasun >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Mon Jul 18 09:17: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 1FCA821F8A66 for ; Mon, 18 Jul 2011 09:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.067 X-Spam-Level: X-Spam-Status: No, score=-102.067 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 Nc5T1IOj-HXd for ; Mon, 18 Jul 2011 09:17:45 -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 667B721F86BA for ; Mon, 18 Jul 2011 09:17:41 -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 p6IGHdNc046801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Jul 2011 11:17:40 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Ben Campbell In-Reply-To: Date: Mon, 18 Jul 2011 11:17:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 18 Jul 2011 16:17:50 -0000 (as chair) Hi Rockson, The change to the CEMA approach from the original "change the path = attribute" approach was the working group consensus after considerable = discussion. As far as I can tell, the points that you brought up were = already considered in that consensus. With all due respect, I recommend = you take a look through the mailing list archives to get a sense of the = many discussions that led to that consensus, and the problems associated = with the path attribute approach. Then if you find that you have new = technical arguments against the change, by all means please bring them = to the list. Thanks! Ben. On Jul 18, 2011, at 5:01 AM, Rockson Li wrote: > Home router is an example of SIP ALG. > most of the > devices would replace all the internal IP addr with public IP addr, > regardless in SIP header or SDP attributes. > Which means a=3Dpath would have to be changed, >=20 >=20 > I am not in favor of implementing MSRP ALG, I just think if this draft > needs cover middle box, SIP ALG needs be covered. > Actually previous session-match approach already fixes this SIP ALG = issue. > Maybe we need figure out a way somehow to put session-match and CEMA > together to cover all the types of middle boxes. >=20 > Thanks > -Rockson >=20 > On 7/18/11 5:43 PM, "I=F1aki Baz Castillo" wrote: >=20 >> 2011/7/18 Rockson Li : >>>> We are talking about SBC-like middleboxes here, not cheap home = routers. >>>> Now, it these middleboxes want to claim they support MSRP media >>>> anchoring, they will need to implement the B2BUA (which is not used = on >>>> every case), that's what is specified in draft 13 right now. >>>=20 >>> Please do remember MSRP is used for IM, which is used by end user = who >>> are >>> connected to Internet with home router. >>> If it cannot go through home router, I don't think MSRP would be >>> successful at all. >>=20 >> A home router should not "play" with SIP neither with MSRP. The >> service provider should/could use server side solutions (as MSRP >> relays) and it's done. >>=20 >> But I don't understand your point: are you in favor of implementing >> MSRP ALG in home routers in the same way they poorly implement SIP = ALG >> (breaking SIP *always*) ? >>=20 >>=20 >> --=20 >> I=F1aki Baz Castillo >> >=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From fluffy@cisco.com Mon Jul 18 13:37: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 4187521F8B10 for ; Mon, 18 Jul 2011 13:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.121 X-Spam-Level: X-Spam-Status: No, score=-104.121 tagged_above=-999 required=5 tests=[AWL=-1.522, 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 tL2RWBeT+giO for ; Mon, 18 Jul 2011 13:37:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F1A1E21F8B07 for ; Mon, 18 Jul 2011 13:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=93; q=dns/txt; s=iport; t=1311021468; x=1312231068; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=VPxbYZYeFuoxhhdaIkodvv+u2IMkc5yE4s2xdrglgIg=; b=H8SzGclK5MXssA7NEkeXCYhOxWfK19aJRRK3pZLsuC+xLdltQ4Dfs1R3 l5VlgqdRSWOtMhXlfFI+ItrLNwq7Kj8wWdn66GWIrs/GLGf4r74ID8DNP ap7QTrO9dPNu756jDE1DVTtRW9wlOs/al28xGOSCVHOYF9E45LQkaM2JV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoIAFKYJE6rRDoH/2dsb2JhbAAhMph7jn93iHajeoEjnjGFXV8Eh1SLEpB1 X-IronPort-AV: E=Sophos;i="4.67,223,1309737600"; d="scan'208";a="4097000" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-3.cisco.com with ESMTP; 18 Jul 2011 20:37:47 +0000 Received: from sjc-vpn3-1134.cisco.com (sjc-vpn3-1134.cisco.com [10.21.68.110]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6IKbk9T032467 for ; Mon, 18 Jul 2011 20:37:47 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2011 13:37:46 -0700 Message-Id: <5718BC32-2C73-4662-AC6E-CA04B6943FA0@cisco.com> To: simple@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Simple] upcoming meeting 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, 18 Jul 2011 20:37:52 -0000 Given I have draft in splices, I will probably be in splices and not = simple. Sorry.=20 From wwwrun@rfc-editor.org Wed Jul 20 19:52: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 5853521F86D6 for ; Wed, 20 Jul 2011 19:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-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 yZQqP9J4mlbB for ; Wed, 20 Jul 2011 19:51:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id 720A221F85F2 for ; Wed, 20 Jul 2011 19:51:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CF41898C4EF; Wed, 20 Jul 2011 19:51:51 -0700 (PDT) To: jdrosen@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, ben@nostrum.com, hisham.khartabil@gmail.com From: RFC Errata System Message-Id: <20110721025151.CF41898C4EF@rfc-editor.org> Date: Wed, 20 Jul 2011 19:51:51 -0700 (PDT) Cc: simple@ietf.org, mustardcy@gmail.com, rfc-editor@rfc-editor.org Subject: [Simple] [Editorial Errata Reported] RFC4826 (2867) 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, 21 Jul 2011 02:52:02 -0000 The following errata report has been submitted for RFC4826, "Extensible Markup Language (XML) Formats for Representing Resource Lists". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4826&eid=2867 -------------------------------------- Type: Editorial Reported by: Yi Chen Section: 3.1 Original Text ------------- The element has a single mandatory attribute, "ref". Corrected Text -------------- The element has a single mandatory attribute, "ref". Notes ----- ref is a mandatory attribute of entry-ref but not entry. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4826 (draft-ietf-simple-xcap-list-usage-05) -------------------------------------- Title : Extensible Markup Language (XML) Formats for Representing Resource Lists Publication Date : May 2007 Author(s) : J. Rosenberg Category : PROPOSED STANDARD Source : SIP for Instant Messaging and Presence Leveraging Extensions Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From christer.holmberg@ericsson.com Sat Jul 23 04:40: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 E003521F8743 for ; Sat, 23 Jul 2011 04:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 84KEiXyLWnTY for ; Sat, 23 Jul 2011 04:40:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF4021F8500 for ; Sat, 23 Jul 2011 04:40:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-9e-4e2ab315b986 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FF.DB.20773.613BA2E4; Sat, 23 Jul 2011 13:40:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Sat, 23 Jul 2011 13:40:05 +0200 From: Christer Holmberg To: Rockson Li Date: Sat, 23 Jul 2011 13:40:04 +0200 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxFZkAz8M3njmMHSp6RBTxw/2Yp4gDNzJ2Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB64704FF@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: Simple WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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: Sat, 23 Jul 2011 11:40:08 -0000 Hi Rockson, Due to summer vacation I have not been able to comment earlier. Sorry for t= hat. However, I have read through the e-mail thread, and I think most things hav= e been said, but just an additional clarification. For interoperability with 4975/4976 devices, MSRP B2BUA behavior needs to b= e enabled in some cases. BUT, that was the case also in the previous versio= ns of sessmatch, so it's nothing that CEMA has introduced. In fact, with CE= MA the number of cases where MSRP B2BUA needs to be enabled is smaller than= in the previous versions of sessmatch. Regards, Christer From HKaplan@acmepacket.com Tue Jul 26 10:02: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 D58D611E80C9 for ; Tue, 26 Jul 2011 10:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] 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 dLOOI5t0xuUR for ; Tue, 26 Jul 2011 10:02:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C762811E8075 for ; Tue, 26 Jul 2011 10:02:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 26 Jul 2011 13:02:45 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Tue, 26 Jul 2011 13:02:45 -0400 From: Hadriel Kaplan To: Rockson Li Date: Tue, 26 Jul 2011 13:02:43 -0400 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxLtdY9EKn45F4FS+GDEf41NEqg7A== Message-ID: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> 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: AAAAAQAAAUA= Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 26 Jul 2011 17:02:49 -0000 Rockson, I've read through the email thread and I'm trying to understand why you thi= nk the changes for sessmatch-13 prevent SBCs/middleboxes from handling MSRP= . Are you simply concerned about the language in the draft which makes the mi= ddlebox revert to being an MSRP B2BUA if the endpoint UA did not support CE= MA? If so, I don't think it will actually matter in the end. If a middlebox ca= n't reasonably be an MSRP B2BUA, then it won't... no matter what an RFC say= s. There is no RFC police on the Internet. As long as the UA's support CE= MA things will work. If they don't support CEMA, it's not going to work re= gardless (or they can go find MSRP Relays to use). -hadriel On Jul 18, 2011, at 3:57 AM, Rockson Li wrote: >=20 > If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for > this mechanism in Internet. > Remember most of the SIP NAT/ALG, regardless your preference, the only > thing they do is mapping the IP addr in the IP/SIP/SDP payload, > I don't think they would ever function as a MSRP B2BUA. >=20 From eburger@standardstrack.com Tue Jul 26 15:39: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 50C3E11E80C0 for ; Tue, 26 Jul 2011 15:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.381 X-Spam-Level: X-Spam-Status: No, score=-102.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 tTAJY7-6OF7i for ; Tue, 26 Jul 2011 15:39:19 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4060011E80BD for ; Tue, 26 Jul 2011 15:39:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=G/3/Km2K9SMhMqV/irnHKTfkMKHMFLaLC1ak2rHYPob4gah0872mk5/kYLuhWErFzmqotKwgoscC//2rSMCoyan6X3IqbBObndMgLcXQ+RMtBKoP555wDSgbdIEsg8BX; Received: from modemcable058.242-23-96.mc.videotron.ca ([96.23.242.58] helo=[192.168.2.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QlqHQ-0000hV-G1; Tue, 26 Jul 2011 15:39:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-123-552784441; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> Date: Tue, 26 Jul 2011 18:39:09 -0400 Message-Id: <9BC21DC0-9337-41B0-B9C9-75C415AAEE12@standardstrack.com> References: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> To: Rockson Li 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 - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 26 Jul 2011 22:39:20 -0000 --Apple-Mail-123-552784441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Agreed. Something doing CEMA will be much more complex and expensive = than a simple B2BUA. If it cannot do B2BUA, it has no prayer of doing = CEMA. On Jul 26, 2011, at 1:02 PM, Hadriel Kaplan wrote: >=20 > Rockson, > I've read through the email thread and I'm trying to understand why = you think the changes for sessmatch-13 prevent SBCs/middleboxes from = handling MSRP. >=20 > Are you simply concerned about the language in the draft which makes = the middlebox revert to being an MSRP B2BUA if the endpoint UA did not = support CEMA? >=20 > If so, I don't think it will actually matter in the end. If a = middlebox can't reasonably be an MSRP B2BUA, then it won't... no matter = what an RFC says. There is no RFC police on the Internet. As long as = the UA's support CEMA things will work. If they don't support CEMA, = it's not going to work regardless (or they can go find MSRP Relays to = use). >=20 > -hadriel >=20 >=20 > On Jul 18, 2011, at 3:57 AM, Rockson Li wrote: >=20 >>=20 >> If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need = for >> this mechanism in Internet. >> Remember most of the SIP NAT/ALG, regardless your preference, the = only >> thing they do is mapping the IP addr in the IP/SIP/SDP payload, >> I don't think they would ever function as a MSRP B2BUA. >>=20 >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple --Apple-Mail-123-552784441 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MjYyMjM5MTBaMCMGCSqGSIb3DQEJ BDEWBBSYdYF01A/4UNuAEnJK1ytS7miOaDCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAHYJA29Yb3dKNqWX+7Fc0BNb7TI3PJ1O/5tj6brY4POWRjAH vdswMzRiViqFivEwXdkCmi5RMFFGFwdJV0MMKy2OSu4AJHk7vJpK2nCWeloekjBpCPzDNWtg+11s zP2MiO5lkQoKstAqU0sq2sZTUgd+W11r4zLgl9Rv9oAVz3e+cqb/UGejO7aU81HLTxfdRr2Jqxn+ R+FmHKfnBtWnTOQOKitihFtDXWShBjnJiVybhFazN9hysna448AIW/3kNK67iZz2litWApQSH7Xj /G+NW5lnXyA1++z+vo3UqmPyFxwIaFUdfUul4skNcMuLeKxloJfSDiA5ZQ8Hpax/iPMAAAAAAAA= --Apple-Mail-123-552784441-- From ben@nostrum.com Tue Jul 26 15:42: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 7503111E80C0 for ; Tue, 26 Jul 2011 15:42: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 etOTegysnwPw for ; Tue, 26 Jul 2011 15:42:48 -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 7ED2011E80BD for ; Tue, 26 Jul 2011 15:42:47 -0700 (PDT) Received: from [10.0.1.2] (dhcp-4197.meeting.ietf.org [130.129.65.151]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QMgfuw054458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Jul 2011 17:42:42 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <9BC21DC0-9337-41B0-B9C9-75C415AAEE12@standardstrack.com> Date: Tue, 26 Jul 2011 18:42:41 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> <9BC21DC0-9337-41B0-B9C9-75C415AAEE12@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 130.129.65.151 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 26 Jul 2011 22:42:48 -0000 Just to be clear--you guys are all using the term B2BUA to refer to an = MSRP intermediary, rather than a SIP intermediary, right? On Jul 26, 2011, at 6:39 PM, Eric Burger wrote: > Agreed. Something doing CEMA will be much more complex and expensive = than a simple B2BUA. If it cannot do B2BUA, it has no prayer of doing = CEMA. >=20 > On Jul 26, 2011, at 1:02 PM, Hadriel Kaplan wrote: >=20 >>=20 >> Rockson, >> I've read through the email thread and I'm trying to understand why = you think the changes for sessmatch-13 prevent SBCs/middleboxes from = handling MSRP. >>=20 >> Are you simply concerned about the language in the draft which makes = the middlebox revert to being an MSRP B2BUA if the endpoint UA did not = support CEMA? >>=20 >> If so, I don't think it will actually matter in the end. If a = middlebox can't reasonably be an MSRP B2BUA, then it won't... no matter = what an RFC says. There is no RFC police on the Internet. As long as = the UA's support CEMA things will work. If they don't support CEMA, = it's not going to work regardless (or they can go find MSRP Relays to = use). >>=20 >> -hadriel >>=20 >>=20 >> On Jul 18, 2011, at 3:57 AM, Rockson Li wrote: >>=20 >>>=20 >>> If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need = for >>> this mechanism in Internet. >>> Remember most of the SIP NAT/ALG, regardless your preference, the = only >>> thing they do is mapping the IP addr in the IP/SIP/SDP payload, >>> I don't think they would ever function as a MSRP B2BUA. >>>=20 >>=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 eburger@standardstrack.com Tue Jul 26 15:56: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 EDAE3228010 for ; Tue, 26 Jul 2011 15:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=0.191, 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 NtHA7NotxXrS for ; Tue, 26 Jul 2011 15:56:14 -0700 (PDT) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4A478228006 for ; Tue, 26 Jul 2011 15:56:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=h5nQet2FWj0DQ+oStHeTBFNB7JwRulvHIMwiYtCWMs6/z5fl2c2fpX2+PGPx9COVeeRGak9nw2lPbAMtxMuRdQhvnHvjEVmEcOkCxclqs2xReISG6eMYg9Vf5o4Zd/DC; Received: from modemcable058.242-23-96.mc.videotron.ca ([96.23.242.58] helo=[192.168.2.111]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QlqXs-0002Sa-1U; Tue, 26 Jul 2011 15:56:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4-553807110; protocol="application/pkcs7-signature"; micalg=sha1 From: Eric Burger In-Reply-To: Date: Tue, 26 Jul 2011 18:56:12 -0400 Message-Id: <8941064B-3A1B-47F2-B974-1E6C63CA5FD4@standardstrack.com> References: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> <9BC21DC0-9337-41B0-B9C9-75C415AAEE12@standardstrack.com> 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 - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: Simple WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 26 Jul 2011 22:56:15 -0000 --Apple-Mail-4-553807110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Affirmative, from my perspective. On Jul 26, 2011, at 6:42 PM, Ben Campbell wrote: > Just to be clear--you guys are all using the term B2BUA to refer to an = MSRP intermediary, rather than a SIP intermediary, right? >=20 > On Jul 26, 2011, at 6:39 PM, Eric Burger wrote: >=20 >> Agreed. Something doing CEMA will be much more complex and expensive = than a simple B2BUA. If it cannot do B2BUA, it has no prayer of doing = CEMA. >>=20 >> On Jul 26, 2011, at 1:02 PM, Hadriel Kaplan wrote: >>=20 >>>=20 >>> Rockson, >>> I've read through the email thread and I'm trying to understand why = you think the changes for sessmatch-13 prevent SBCs/middleboxes from = handling MSRP. >>>=20 >>> Are you simply concerned about the language in the draft which makes = the middlebox revert to being an MSRP B2BUA if the endpoint UA did not = support CEMA? >>>=20 >>> If so, I don't think it will actually matter in the end. If a = middlebox can't reasonably be an MSRP B2BUA, then it won't... no matter = what an RFC says. There is no RFC police on the Internet. As long as = the UA's support CEMA things will work. If they don't support CEMA, = it's not going to work regardless (or they can go find MSRP Relays to = use). >>>=20 >>> -hadriel >>>=20 >>>=20 >>> On Jul 18, 2011, at 3:57 AM, Rockson Li wrote: >>>=20 >>>>=20 >>>> If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need = for >>>> this mechanism in Internet. >>>> Remember most of the SIP NAT/ALG, regardless your preference, the = only >>>> thing they do is mapping the IP addr in the IP/SIP/SDP payload, >>>> I don't think they would ever function as a MSRP B2BUA. >>>>=20 >>>=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 >=20 --Apple-Mail-4-553807110 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCCBN0w ggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0Ix GzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwR Q29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0w NDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQx FzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsx ITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJz dC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVNNRm5pELlzkniii8efNIx B8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8 om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHG TPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7Nl yP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0j BBgwFoAUoBEKIz6W8Qfs4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59 MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5j b21vZG9jYS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwu Y29tb2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvzbRx8 NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12jMOCAU9s APMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxogL5dMUbtGB8SK N04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNBpEMD9O3vMyfbOeAU TibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mYHK9/FX8wggY6MIIFIqAD AgECAhEAxcM7lN0zgrA71mfq+sG6xjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMDA5MDgwMDAw MDBaFw0xMTA5MDgyMzU5NTlaMIHhMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNl OiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21v ZG8gTGltaXRlZDEUMBIGA1UEAxMLRXJpYyBCdXJnZXIxKTAnBgkqhkiG9w0BCQEWGmVidXJnZXJA c3RhbmRhcmRzdHJhY2suY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqeauFkEq 5Pj7AIAaDRbUWIpoblTKyrjcSfXRaHvjk0jWBTsBPe6oOZjudMK0Vo9A1Sl52BixDgf1/qb2Z+PT 7M0mqSOOsSucEBid48IMvGi79xmKKAVf5jiyFNNAaTZWn76dwNLMkKd/+Ki0fn8kEbb2zG+gGKyZ MNHiNX+GQfPpHyzo2MTwnb16lXMfGJrGv4uLZS/pY9PENdFQnwV0ASZoqX+ArtLY2xeuC+rYG9xQ Cz7qiLbJhCJzWsEGETyHLDjE5bN4HB9DsJKtGFLQuOdTanwGigNz9cVH9pLFNQxiotavAouXgqS4 wGvcq4mGP9w9zTychoUqIKsEg9OD1wIDAQABo4ICHDCCAhgwHwYDVR0jBBgwFoAUiYJnfcSdJnAA S7RQSHzePa4Ebn0wHQYDVR0OBBYEFAlgEOVj6Hl0La8sPRP388HEMiWvMA4GA1UdDwEB/wQEAwIF oDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0 cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVtYWls LmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0 aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRw Oi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmNvbW9kb2NhLmNvbTAlBgNVHREEHjAcgRplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNv bTANBgkqhkiG9w0BAQUFAAOCAQEACRTppSEc5DMYn8YXcbfX36iTaNBGw1gUvTNam0U8pXH0E7H3 2d4cTq6DEMu5ifEvxMGBqhUyv0sKxQ7+UvtDwrk7Kiy2L6TUC4zNEklZbtDqY7+Wd7EQZkN4k/zx kMLlz2VIIRL/Cg48NrBKP5bo1la78NTJx8m4+VForLseEBabxMQoWB/GOVC7WpO/+RCgd93gz6H/ RzW1hnK0Uvu5H3Kz7HEC3R1Qk/sE9nXVzTfoJOMJRnyMS5Ut61mgoWSm/kUtczAlRRYh6IBOhzAl awoXz+yk9hMCheYRAWx0EamBBpSzvqXj0N2vXYc62v3e3ddcLZncjiB0pYIfCE3s4DGCA/8wggP7 AgEBMIHEMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cu dXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhEAxcM7lN0zgrA71mfq+sG6xjAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMTA3MjYyMjU2MTJaMCMGCSqGSIb3DQEJ BDEWBBRqaS7JRu4ZMDmuHCx6gUlUyN41mjCB1QYJKwYBBAGCNxAEMYHHMIHEMIGuMQswCQYDVQQG EwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQG A1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhEAxcM7 lN0zgrA71mfq+sG6xjCB1wYLKoZIhvcNAQkQAgsxgceggcQwga4xCzAJBgNVBAYTAlVTMQswCQYD VQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1Qg TmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQDFwzuU3TOCsDvWZ+r6 wbrGMA0GCSqGSIb3DQEBAQUABIIBAE7/eO06UVwFw0lzBjx4pAhvS6TCVE1eggHU24klUz5U7THC WxPI8rSwEJ/qd1Mh0C2B6WC6wxupXBzWHNOI7JViTfJiJyumZalvF28ONJq45un+V6JQjzlppRhu kwLkG9JjJC0lkcpW3zTySOt8OM5BlWPTxmaYGq0BZnUpZJ3kpZW0FjUWxGazhNbCAbUo+8r+0xxt xSiTn0mfGfMUvYyK+qnNTEnKDuxgR+6cvmK+x8B0XqnS4EtXLW19RBVH/IBKhGhGNhMMGjzImQME Gw0LIYzebVLjNoyuizlz8MO7nXhy6nRFL1AHIy7xG7G/bqmd9oDGcdTsXiqutqLkvOwAAAAAAAA= --Apple-Mail-4-553807110-- From zhengyli@cisco.com Tue Jul 26 22:46: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 B996821F8678 for ; Tue, 26 Jul 2011 22:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.105 X-Spam-Level: X-Spam-Status: No, score=-10.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Gz6CPd68dZEk for ; Tue, 26 Jul 2011 22:46:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AB37E21F85EE for ; Tue, 26 Jul 2011 22:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=zhengyli@cisco.com; l=3081; q=dns/txt; s=iport; t=1311745567; x=1312955167; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=RqCwzjzWPHNglZ3ex3Pchh3Gnm7d8F2Vy2wwNJGWcpc=; b=XJz1WRB+R1NCCkPT9zx9Wd0HooYwtRIOdQnDcdPJR6rM59GH+FAYU+0y t/hKH+JGM0Qk5/6u2YL9lMAJkPb1gqYa+WocUZ7kLOyOE4bNO1gL4D8rB kogMUEvT3O/tKgdHFXmlNdZVHZW4Hu1k+RKnudmNpbQ0gD6Ns26EI8SuJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAMakL05Io8US/2dsb2JhbAA1AQEBAQMUARgTAwFBFAkOCk5RBw8IIAenKXesIp5XhkAEh1WLIIUHi2g X-IronPort-AV: E=Sophos;i="4.67,274,1309737600"; d="scan'208";a="44606328" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 27 Jul 2011 05:46:04 +0000 Received: from [64.104.167.37] ([64.104.167.37]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p6R5k1cN017972; Wed, 27 Jul 2011 05:46:02 GMT User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 27 Jul 2011 13:45:59 +0800 From: Rockson Li To: Hadriel Kaplan Message-ID: Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 In-Reply-To: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 05:46:08 -0000 Hadriel, I think CEMA has a assumption that the middle box should be a SIP proxy like entity,i.e, path attribute must be forwarded across the middle box intact. In that case, as you said, the solution can work if UA supports CEMA. However, the point is it cannot address the issue if the path uri does not get passed onwards intact in some circumstances. Suppose the following two cases, 1) SBC is used between two MSRP UAs A SBC B ------------------> a=path:msrp://ipA/sessid-a;tcp ---------------------> a=path:msrp://ipSBC/sessid-a;tcp When SBC fwds the path uri from A to B , for topology hiding purpose, SBC would like to replace the host part of path uri to itself and retain the sessid part. 2) SBC-ALG is used between two MSRP UAs A NAT/SBC-ALG B ------------------> a=path:msrp://ipA/sessid-a;tcp ---------------------> a=path:msrp://ipPUB/sessid-a;tcp Many SIP-ALG would replace the private IP with its public IP regardless its in c/m/a lines of SDP, it could be argued this is a perfect behavior. However, as far as I know, many SIP-ALGs just do this for simplicity. In both of the cases above, MSRP for SBC/SIP-ALG is of no difference to other audio/video media streams, SBC/SBC-ALG just need fwd any traffic destined to ipSBC to ipA like a TCP NAT, without awareness the semantics inside those traffic if A can match the MSRP session simply based on session id. However, with CEMA, SBC/SIP-ALG cannot transparently fwd the traffic with the change it made to the path uri. It has to be a MSRP B2BUA for that path uri change, otherwise fwd the path URI intact end to end as assumption of middle box in CEMA draft mandates. -Rockson On 7/27/11 1:02 AM, "Hadriel Kaplan" wrote: > >Rockson, >I've read through the email thread and I'm trying to understand why you >think the changes for sessmatch-13 prevent SBCs/middleboxes from handling >MSRP. > >Are you simply concerned about the language in the draft which makes the >middlebox revert to being an MSRP B2BUA if the endpoint UA did not >support CEMA? > >If so, I don't think it will actually matter in the end. If a middlebox >can't reasonably be an MSRP B2BUA, then it won't... no matter what an RFC >says. There is no RFC police on the Internet. As long as the UA's >support CEMA things will work. If they don't support CEMA, it's not >going to work regardless (or they can go find MSRP Relays to use). > >-hadriel > > >On Jul 18, 2011, at 3:57 AM, Rockson Li wrote: > >> >> If MSRP cannot traverse NAT/ALG/SBC, I don't think there's no need for >> this mechanism in Internet. >> Remember most of the SIP NAT/ALG, regardless your preference, the only >> thing they do is mapping the IP addr in the IP/SIP/SDP payload, >> I don't think they would ever function as a MSRP B2BUA. >> > From saul@ag-projects.com Wed Jul 27 00:52: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 3FF9121F8BD5 for ; Wed, 27 Jul 2011 00:52:48 -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 1hbCPLEPW2Hq for ; Wed, 27 Jul 2011 00:52:47 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7830521F8BD4 for ; Wed, 27 Jul 2011 00:52:46 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id DE5B1B01B7; Wed, 27 Jul 2011 09:52:44 +0200 (CEST) Received: from [192.168.1.36] (45.Red-81-36-29.dynamicIP.rima-tde.net [81.36.29.45]) by mail.sipthor.net (Postfix) with ESMTPSA id 78D7AB0181; Wed, 27 Jul 2011 09:52:31 +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, 27 Jul 2011 09:52:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7969F8FB-789E-4880-9348-507967134292@ag-projects.com> References: To: Rockson Li X-Mailer: Apple Mail (2.1084) Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 07:52:48 -0000 Hi Rockson, On Jul 27, 2011, at 7:45 AM, Rockson Li wrote: > Hadriel, >=20 > I think CEMA has a assumption that the middle box should be a SIP = proxy > like entity,i.e, path attribute must be forwarded across the middle = box > intact. > In that case, as you said, the solution can work if UA supports CEMA. >=20 > However, the point is it cannot address the issue if the path uri does = not > get passed onwards intact in some circumstances. >=20 The first problem I see is that for some reason it is assumed that the = a=3Dpath attribute can be mangled. It can't be mangled. Of course you = can mangle it, but not without breaking things. If that behavior would = be changed, it would break compatibility with RFC 4975, 4976 devices, = and I would never do that for the sole purpose of media anchoring and/or = NAT traversal because there are already working mechanisms to achieve = those. > Suppose the following two cases, >=20 > 1)=20 > SBC is used between two MSRP UAs > A SBC B > ------------------> > a=3Dpath:msrp://ipA/sessid-a;tcp > ---------------------> > a=3Dpath:msrp://ipSBC/sessid-a;tcp > When SBC fwds the path uri from A to B , for topology hiding = purpose, > SBC would like to replace the host part of path uri to itself and = retain > the sessid part. >=20 >=20 > 2) SBC-ALG is used between two MSRP UAs > A NAT/SBC-ALG B > ------------------> > a=3Dpath:msrp://ipA/sessid-a;tcp > ---------------------> > a=3Dpath:msrp://ipPUB/sessid-a;tcp >=20 >=20 > Many SIP-ALG would replace the private IP with its public IP = regardless > its in c/m/a lines of SDP, it could be argued this is a perfect = behavior. > However, as far as I know, many SIP-ALGs just do this for simplicity. >=20 I don't think they do it for simplicity. The probably do it because this = "worked" for audio/video streams, but they never envisioned other media = types which would differently. >=20 > In both of the cases above, MSRP for SBC/SIP-ALG is of no difference = to > other audio/video media streams, SBC/SBC-ALG just need fwd any traffic > destined to ipSBC to ipA like a TCP NAT, > without awareness the semantics inside those traffic if A can match = the > MSRP session simply based on session id. >=20 > However, with CEMA, SBC/SIP-ALG cannot transparently fwd the traffic = with > the change it made to the path uri. > It has to be a MSRP B2BUA for that path uri change, otherwise fwd the = path > URI intact end to end as assumption of middle box in CEMA draft = mandates. >=20 I do understand your point with regards to topology hiding, but because = of how the protocol is designed and the semantics of the a=3Dpath line I = don't see how this can be solved in a way that works for everybody. = Also, this issue wasn't raised before, looks like everyone was happy = that media could be anchored with CEMA while maintaining plain MSRP = compatibility.=20 So, is topology hiding a show-stopper? I guess this is the question. For = me, personally, it's not.=20 Regards, --=20 Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Jul 27 02:08: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 8F53021F88A0 for ; Wed, 27 Jul 2011 02:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, 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 DCk-JU+2NZsx for ; Wed, 27 Jul 2011 02:08:44 -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 9501921F884F for ; Wed, 27 Jul 2011 02:08:44 -0700 (PDT) Received: by qwc23 with SMTP id 23so919225qwc.31 for ; Wed, 27 Jul 2011 02:08:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.251.6 with SMTP id mq6mr4971431qcb.291.1311757723343; Wed, 27 Jul 2011 02:08:43 -0700 (PDT) Received: by 10.229.224.212 with HTTP; Wed, 27 Jul 2011 02:08:43 -0700 (PDT) In-Reply-To: References: <8CE5997A-9816-49F1-B894-2171C40AF7E2@acmepacket.com> Date: Wed, 27 Jul 2011 11:08:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Rockson Li Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 09:08:45 -0000 2011/7/27 Rockson Li : > I think CEMA has a assumption that the middle box should be a SIP proxy Yes, a SIP proxy or a SIP B2BUA, anything *real* and *valid* at SIP level (and not a TCP/IP router than mangles data at application level). This WG has discussed the existence of SIPALG routers [*], those that are not SIP entities but just inspect SIP messages and apply annoying substitutions over them based on even more annoying regular expressions ( s/PRIVATE_IP/PUBLIC_IP/g ). Those routers with SIP-ALG built-in are a pain and this WG has states that CEMA is *not* for them, but for real SIP entities (SIP proxies or B2BUA), maybe called SBC's. But as per your comments and other comments, I think that the above is not true and vendors *do* want to implement sessmatch/CEMA in ugly SIP-ALG routers (like any home router provided by any Internet provider in the world). I'm a bit afraid. Regards. [*] http://www.voip-info.org/wiki/view/Routers+SIP+ALG --=20 I=C3=B1aki Baz Castillo From HKaplan@acmepacket.com Wed Jul 27 11:12: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 A222621F847D for ; Wed, 27 Jul 2011 11:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 CJdd59+aRIlq for ; Wed, 27 Jul 2011 11:12:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A43521F84C5 for ; Wed, 27 Jul 2011 11:12:24 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Jul 2011 14:12:21 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 14:12:21 -0400 From: Hadriel Kaplan To: Rockson Li Date: Wed, 27 Jul 2011 14:12:09 -0400 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxMiLXik+ihQCE0TySgLbhFB1zCxQ== Message-ID: 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: AAAAAQAAAUA= Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 18:12:26 -0000 On Jul 27, 2011, at 1:45 AM, Rockson Li wrote: > Suppose the following two cases, >=20 > 1)=20 > SBC is used between two MSRP UAs > A SBC B > ------------------> > a=3Dpath:msrp://ipA/sessid-a;tcp > ---------------------> > a=3Dpath:msrp://ipSBC/sessid-a;tcp > When SBC fwds the path uri from A to B , for topology hiding purpose, > SBC would like to replace the host part of path uri to itself and retain > the sessid part. >=20 Topology hiding wasn't possible, even in previous sessmatch drafts. The re= ason is even if the SBC modified/replaced the path attributes, the UA would= still *use* the path attribute it originally sent in the MSRP messages the= mselves. In other words, device A in the above diagram would use "msrp://ipA/sessid-= a" in its from-path header in the MSRP messages it sends to B; and likewise= B would use "msrp://ipSBC/sessid-a" in its from-path in the messages it se= nds to A. So A and B will discover those path addresses regardless of the = SBC changing them in the SDP. The only way to really hide those would be f= or the SBC to be an MSRP B2BUA, or for the UAs themselves to use anonymous = addressing.=20 -hadriel From HKaplan@acmepacket.com Wed Jul 27 11:22: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 6451711E8142 for ; Wed, 27 Jul 2011 11:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 FVprx3QAPYWn for ; Wed, 27 Jul 2011 11:22:36 -0700 (PDT) Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id C48AE11E8081 for ; Wed, 27 Jul 2011 11:22:35 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 27 Jul 2011 14:02:35 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 14:21:47 -0400 From: Hadriel Kaplan To: Saul Ibarra Corretge Date: Wed, 27 Jul 2011 14:20:50 -0400 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxMigdgnOehdyrBSzqJL/LHJq1JSA== Message-ID: <1625D7E2-85C8-4197-8091-9AF6303C8E13@acmepacket.com> References: <7969F8FB-789E-4880-9348-507967134292@ag-projects.com> In-Reply-To: <7969F8FB-789E-4880-9348-507967134292@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: AAAAAQAAAUA= Cc: "simple@ietf.org" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 18:22:36 -0000 On Jul 27, 2011, at 3:52 AM, Saul Ibarra Corretge wrote: > I do understand your point with regards to topology hiding, but because o= f how the protocol is designed and the semantics of the a=3Dpath line I don= 't see how this can be solved in a way that works for everybody. Also, this= issue wasn't raised before, looks like everyone was happy that media could= be anchored with CEMA while maintaining plain MSRP compatibility.=20 It was raised before, and in fact one of the original draft proposals for h= andling crossing middleboxes included topology hiding: http://tools.ietf.org/html/draft-macdonald-simple-msrp-opaque-path-01 But in the choice between that draft and the ACM draft, the working group c= hose the ACM draft. -hadriel From HKaplan@acmepacket.com Wed Jul 27 11:25: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 F1D1911E8084 for ; Wed, 27 Jul 2011 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] 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 u0WJw3cM14Sv for ; Wed, 27 Jul 2011 11:25:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0363E11E8081 for ; Wed, 27 Jul 2011 11:25:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 27 Jul 2011 14:25:07 -0400 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Wed, 27 Jul 2011 14:25:07 -0400 From: Hadriel Kaplan To: Rockson Li Date: Wed, 27 Jul 2011 14:25:05 -0400 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxMioI69NB4mzEKQeexGkWyJ1tYqQ== Message-ID: 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: AAAAAQAAAUA= Cc: "simple@ietf.org WG" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 18:25:09 -0000 On Jul 27, 2011, at 2:12 PM, Hadriel Kaplan wrote: >=20 > On Jul 27, 2011, at 1:45 AM, Rockson Li wrote: >=20 >> Suppose the following two cases, >>=20 >> 1)=20 >> SBC is used between two MSRP UAs >> A SBC B >> ------------------> >> a=3Dpath:msrp://ipA/sessid-a;tcp >> ---------------------> >> a=3Dpath:msrp://ipSBC/sessid-a;tcp >> When SBC fwds the path uri from A to B , for topology hiding purpose, >> SBC would like to replace the host part of path uri to itself and retain >> the sessid part. >>=20 >=20 > Topology hiding wasn't possible, even in previous sessmatch drafts. The = reason is even if the SBC modified/replaced the path attributes, the UA wou= ld still *use* the path attribute it originally sent in the MSRP messages t= hemselves. >=20 > In other words, device A in the above diagram would use "msrp://ipA/sessi= d-a" in its from-path header in the MSRP messages it sends to B; and likewi= se B would use "msrp://ipSBC/sessid-a" in its from-path in the messages it = sends to A. =20 Sorry meant B would use "msrp://ipB/sessid-b". > So A and B will discover those path addresses regardless of the SBC chang= ing them in the SDP. The only way to really hide those would be for the SB= C to be an MSRP B2BUA, or for the UAs themselves to use anonymous addressin= g.=20 >=20 > -hadriel >=20 > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Wed Jul 27 12:43: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 9378511E8110 for ; Wed, 27 Jul 2011 12:43: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 fgKlJE25Rk4Q for ; Wed, 27 Jul 2011 12:43:31 -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 B9C7811E80F2 for ; Wed, 27 Jul 2011 12:43:30 -0700 (PDT) Received: from [10.0.1.2] (dhcp-4197.meeting.ietf.org [130.129.65.151]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6RJhSfD077544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 27 Jul 2011 14:43:29 -0500 (CDT) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2011 15:43:28 -0400 Message-Id: <4775FF34-1812-4C19-A1DF-FEB2843B5520@nostrum.com> To: Simple WG Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 130.129.65.151 is authenticated by a trusted mechanism) Subject: [Simple] Meeting Administrivia 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, 27 Jul 2011 19:43:31 -0000 Hi, We have a 1 hour slot for the SIMPLE meeting on Friday. In order to use = time efficiently, can I get advance volunteers for the following? 1) Minute Taker - Capture issues, issue resolution, and action items. 2) Jabber Scribe - Watch for comments from chatroom, and bring to mike = if needed. 3) Alternate Minute Taker (optional, but really nice to have.) Thanks! Ben.= From Martin.Thomson@commscope.com Wed Jul 27 12:46: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 C3D7311E8084 for ; Wed, 27 Jul 2011 12:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] 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 L5p1+JqofY2S for ; Wed, 27 Jul 2011 12:46:22 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37511E8073 for ; Wed, 27 Jul 2011 12:46:22 -0700 (PDT) X-AuditID: 0a0404e8-b7c24ae000002adb-8e-4e306b19782b Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id B8.B7.10971.91B603E4; Wed, 27 Jul 2011 14:46:33 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 27 Jul 2011 14:46:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 27 Jul 2011 14:46:19 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 28 Jul 2011 03:46:19 +0800 From: "Thomson, Martin" To: Ben Campbell , Simple WG Date: Thu, 28 Jul 2011 03:46:16 +0800 Thread-Topic: [Simple] Meeting Administrivia Thread-Index: AcxMlXnjzkxh63m1Rl6UUuUilpyr9AAACwQg Message-ID: <8B0A9FCBB9832F43971E38010638454F040D2C37AE@SISPE7MB1.commscope.com> References: <4775FF34-1812-4C19-A1DF-FEB2843B5520@nostrum.com> In-Reply-To: <4775FF34-1812-4C19-A1DF-FEB2843B5520@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== Subject: Re: [Simple] Meeting Administrivia 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, 27 Jul 2011 19:46:23 -0000 I hate to correct your English, but the correct word is "Alternative". Unl= ess you meant for the two note takers to capture alternating decisions. And yes, that is me volunteering for one of those roles. I know how this w= orks. On 2011-07-27 at 15:43:28, Ben Campbell wrote: > Hi, >=20 > We have a 1 hour slot for the SIMPLE meeting on Friday. In order to=20 > use time efficiently, can I get advance volunteers for the following? >=20 > 1) Minute Taker - Capture issues, issue resolution, and action items. > 2) Jabber Scribe - Watch for comments from chatroom, and bring to mike=20 > if needed. > 3) Alternate Minute Taker (optional, but really nice to have.) >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www.ietf.org/mailman/listinfo/simple From ben@nostrum.com Wed Jul 27 13:00: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 ED5AE21F89B8 for ; Wed, 27 Jul 2011 13:00:39 -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 N14FTteqNj0v for ; Wed, 27 Jul 2011 13:00:39 -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 C3D3321F8997 for ; Wed, 27 Jul 2011 13:00:33 -0700 (PDT) Received: from [10.0.1.2] (dhcp-4197.meeting.ietf.org [130.129.65.151]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6RK0Uv9079291 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2011 15:00:32 -0500 (CDT) (envelope-from ben@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D2C37AE@SISPE7MB1.commscope.com> Date: Wed, 27 Jul 2011 16:00:30 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4043AA96-0BA4-41CF-971D-AF6E2927CE6B@nostrum.com> References: <4775FF34-1812-4C19-A1DF-FEB2843B5520@nostrum.com> <8B0A9FCBB9832F43971E38010638454F040D2C37AE@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1244.3) Received-SPF: pass (nostrum.com: 130.129.65.151 is authenticated by a trusted mechanism) Cc: Simple WG Subject: Re: [Simple] Meeting Administrivia 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, 27 Jul 2011 20:00:40 -0000 Thanks, Martin, we will put you down for Minute Taker (non-alternating). And by the way: my dictionary also lists "alternate" as an adjective = describing a "replacement", as in "the rerouted traffic takes a variety = of alternate routes." That was what I had in mind, but I realize it's = not _quite_ right. :-)=20 On Jul 27, 2011, at 3:46 PM, Thomson, Martin wrote: > I hate to correct your English, but the correct word is "Alternative". = Unless you meant for the two note takers to capture alternating = decisions. >=20 > And yes, that is me volunteering for one of those roles. I know how = this works. >=20 > On 2011-07-27 at 15:43:28, Ben Campbell wrote: >> Hi, >>=20 >> We have a 1 hour slot for the SIMPLE meeting on Friday. In order to=20= >> use time efficiently, can I get advance volunteers for the following? >>=20 >> 1) Minute Taker - Capture issues, issue resolution, and action items. >> 2) Jabber Scribe - Watch for comments from chatroom, and bring to = mike=20 >> if needed. >> 3) Alternate Minute Taker (optional, but really nice to have.) >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> Simple mailing list >> Simple@ietf.org >> https://www.ietf.org/mailman/listinfo/simple >=20 >=20 From christer.holmberg@ericsson.com Wed Jul 27 14:32: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 952DD228018 for ; Wed, 27 Jul 2011 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.559 X-Spam-Level: X-Spam-Status: No, score=-6.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 uAnxBm2qw38k for ; Wed, 27 Jul 2011 14:32:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B4E77228017 for ; Wed, 27 Jul 2011 14:32:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-df-4e3083e51c50 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 99.48.20773.5E3803E4; Wed, 27 Jul 2011 23:32:21 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 27 Jul 2011 23:32:21 +0200 From: Christer Holmberg To: Hadriel Kaplan , Rockson Li Date: Wed, 27 Jul 2011 23:28:01 +0200 Thread-Topic: [Simple] On draft-ietf-simple-msrp-sessmatch-13 Thread-Index: AcxMioI69NB4mzEKQeexGkWyJ1tYqQAGY3YB Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FE8@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: "simple@ietf.org WG" Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 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, 27 Jul 2011 21:32:23 -0000 Hi, Hadriel is correct. The previous version of the draft perhaps allowed topology hiding on the si= gnalling level, but the information would still be revealed in the MSRP mes= sages. So, if you want full MSPR topology hiding, you need to enable MSPR B2BUA - = no matter if you use CEMA/sessmatch or not. Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Hadrie= l Kaplan [HKaplan@acmepacket.com] Sent: Wednesday, July 27, 2011 9:25 PM To: Rockson Li Cc: simple@ietf.org WG Subject: Re: [Simple] On draft-ietf-simple-msrp-sessmatch-13 On Jul 27, 2011, at 2:12 PM, Hadriel Kaplan wrote: > > On Jul 27, 2011, at 1:45 AM, Rockson Li wrote: > >> Suppose the following two cases, >> >> 1) >> SBC is used between two MSRP UAs >> A SBC B >> ------------------> >> a=3Dpath:msrp://ipA/sessid-a;tcp >> ---------------------> >> a=3Dpath:msrp://ipSBC/sessid-a;tcp >> When SBC fwds the path uri from A to B , for topology hiding purpose, >> SBC would like to replace the host part of path uri to itself and retain >> the sessid part. >> > > Topology hiding wasn't possible, even in previous sessmatch drafts. The = reason is even if the SBC modified/replaced the path attributes, the UA wou= ld still *use* the path attribute it originally sent in the MSRP messages t= hemselves. > > In other words, device A in the above diagram would use "msrp://ipA/sessi= d-a" in its from-path header in the MSRP messages it sends to B; and likewi= se B would use "msrp://ipSBC/sessid-a" in its from-path in the messages it = sends to A. Sorry meant B would use "msrp://ipB/sessid-b". > So A and B will discover those path addresses regardless of the SBC chang= ing them in the SDP. The only way to really hide those would be for the SB= C to be an MSRP B2BUA, or for the UAs themselves to use anonymous addressin= g. > > -hadriel > > _______________________________________________ > 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 aallen@rim.com Fri Jul 29 08:07: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 C59C221F8C4B for ; Fri, 29 Jul 2011 08:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.194 X-Spam-Level: X-Spam-Status: No, score=-5.194 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 2UiqXWMFdZLj for ; Fri, 29 Jul 2011 08:07:20 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id C4DED21F8C48 for ; Fri, 29 Jul 2011 08:07:20 -0700 (PDT) X-AuditID: 0a412830-b7c48ae000006473-4c-4e32cc9d7a15 Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 41.5D.25715.E9CC23E4; Fri, 29 Jul 2011 15:07:10 +0000 (GMT) Received: from XCT102ADS.rim.net (10.67.111.43) by XHT104CNC.rim.net (10.65.22.52) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 11:07:18 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT102ADS.rim.net ([fe80::4806:2e1d:2b7c:cfdf%22]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 10:07:17 -0500 From: Andrew Allen To: "simple@ietf.org" Thread-Topic: Comment on draft-ietf-msrp-sessmatch-13 Thread-Index: AcxOATRbOaVT3gjhSvSEBFRWyWvjlQ== Date: Fri, 29 Jul 2011 15:07:16 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42LhchQz0Z13xsjPYMkXPouFE/+xOjB6LFny kymAMaqB0SYxLy+/JLEkVSEltTjZVsknNT0xRyGgKLMsMblSwSWzODknMTM3tUhJITPFVslE SaEgJzE5NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2eki gYR/3Bnf/t5hL7jFUnF6fQtjA+Md5i5GTg4JAROJxQens0HYYhIX7q0Hsrk4hAR6mCQW/Opk AUkICSxllLh7LQ4isYVR4vHZa2AdbALKEst/z2AEsUUE1CUeHn3ACmILCxhItCzYxQ4RN5WY 9mkCUxcjB5CtJ/FkaTRImEVAVWL3r8dg83kF3CTe3JjPBGIzCshK7D57HcxmFhCXuPUEIi4h ICCxZM95qKNFJV4+/scKYStKPGnczAJRrydxY+oUNghbW2LZwtfMEPMFJU7OfAL1i7TEjpNr GCcwis5CsmIWkvZZSNpnIWlfwMiyilEwN6PYwMwwOS9ZrygzVy8vtWQTIzj2NQx2ME7Yq3WI UYCDUYmH99tRIz8h1sSy4srcQ4wSHMxKIrwpiw39hHhTEiurUovy44tKc1KLDzFaAENiIrMU d3I+MC3llcQbGxigcJTEecOkDfyEBNKBiSc7NbUgtQimlYmDU6qBMS9y26T307g6E7l87wXN vCc7y0L04hTuC3OVFXgXvknWZZVbwnaqO7tY1PnIn10f/ZsvNs8KXul9IaJoD9vmPXNO3rS0 /mAi5PE8ac3HR596z50PvsvZWK4Rv7LpiqjGStYJ1eF2Mt5TXFTDtxWopvq7JkQYzbocsPNi /BNuk4Bds/amu/esVmIpzkg01GIuKk4EAOMS7uYWAwAA Subject: [Simple] Comment on draft-ietf-msrp-sessmatch-13 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: Fri, 29 Jul 2011 15:07:21 -0000 Christer I have reviewed this draft and I am basically supportive of it. One comment I have is that in 4.2 there is discussion of fallback behavior w= here the middlebox decides to act as B2BUA after it receives the first respo= nse based on a new offer within the same dialog. To act as a B2BUA the middl= ebox needs to determine to be a B2BUA when handling the dialog creating requ= est so the fallback scenario requires the MSRP endpoint to cancel the existi= ng dialog and send the revised offer in a new dialog creating request (not i= n a request on an existing dialog). Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Fri Jul 29 08:38: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 2D53B21F8B0E for ; Fri, 29 Jul 2011 08:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 BY22yJst5oAR for ; Fri, 29 Jul 2011 08:38:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5E28621F8B0A for ; Fri, 29 Jul 2011 08:38:38 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-e2-4e32d3fc9024 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.21.20773.CF3D23E4; Fri, 29 Jul 2011 17:38:36 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.123]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 29 Jul 2011 17:38:36 +0200 From: Christer Holmberg To: Andrew Allen , "simple@ietf.org" Date: Fri, 29 Jul 2011 17:35:43 +0200 Thread-Topic: Comment on draft-ietf-msrp-sessmatch-13 Thread-Index: AcxOATRbOaVT3gjhSvSEBFRWyWvjlQAA/mS1 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FED@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] Comment on draft-ietf-msrp-sessmatch-13 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: Fri, 29 Jul 2011 15:38:39 -0000 Hi Andrew, The middlebox does not send a new offer - it is the task of the CEMA UA. Th= e middlebox simply decides to either enable MSRP B2BUA. We did not want to = start specifying procedures abuot middleboxes sending offers etc. Having said that, one comment that you (and some others) have given is that= the middlebox needed to determine whether to enable MSRP B2BUA when it rec= eives the SDP offer, and I will address that. Thanks! Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Andrew= Allen [aallen@rim.com] Sent: Friday, July 29, 2011 6:07 PM To: simple@ietf.org Subject: [Simple] Comment on draft-ietf-msrp-sessmatch-13 Christer I have reviewed this draft and I am basically supportive of it. One comment I have is that in 4.2 there is discussion of fallback behavior = where the middlebox decides to act as B2BUA after it receives the first res= ponse based on a new offer within the same dialog. To act as a B2BUA the mi= ddlebox needs to determine to be a B2BUA when handling the dialog creating = request so the fallback scenario requires the MSRP endpoint to cancel the e= xisting dialog and send the revised offer in a new dialog creating request = (not in a request on an existing dialog). Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ Simple mailing list Simple@ietf.org https://www.ietf.org/mailman/listinfo/simple= From aallen@rim.com Fri Jul 29 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 2D3A821F86AD for ; Fri, 29 Jul 2011 08:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.195 X-Spam-Level: X-Spam-Status: No, score=-5.195 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 0AdbK+ezXVKe for ; Fri, 29 Jul 2011 08:45:37 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 57E7E21F867F for ; Fri, 29 Jul 2011 08:45:35 -0700 (PDT) X-AuditID: 0a412830-b7c48ae000006473-d5-4e32d5822a27 Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id B1.A0.25715.285D23E4; Fri, 29 Jul 2011 15:45:06 +0000 (GMT) Received: from XCT101ADS.rim.net (10.67.111.42) by XHT107CNC.rim.net (10.65.12.217) with Microsoft SMTP Server (TLS) id 8.3.159.2; Fri, 29 Jul 2011 11:45:15 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT101ADS.rim.net ([fe80::2c7e:1215:d554:35b5%20]) with mapi id 14.01.0289.001; Fri, 29 Jul 2011 10:45:13 -0500 From: Andrew Allen To: "christer.holmberg@ericsson.com" , "simple@ietf.org" Thread-Topic: [Simple] Comment on draft-ietf-msrp-sessmatch-13 Thread-Index: AcxOATRbOaVT3gjhSvSEBFRWyWvjlQAA/mS1AABUz94= Date: Fri, 29 Jul 2011 15:45:13 +0000 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851DB6190FED@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.251] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsXC5chzU7fpqpGfwZrJyhYXZh5mtFg48R+r A5PHr69X2TyWLPnJFMAU1cBok5iXl1+SWJKqkJJanGyr5JOanpijEFCUWZaYXKngklmcnJOY mZtapKSQmWKrZKKkUJCTmJyam5pXYquUWFCQmpeiZMelgAFsgMoy8xRS85LzUzLz0m2VPIP9 dS0sTC11DZXsdJFAwj/ujOmvZjEWXBapaN38nq2Bcb5gFyMnh4SAicTGX1+ZIWwxiQv31rN1 MXJxCAn0Mkkc+vmDCcJZxigx79g1VghnC6PEzPuHGEFa2ASUJZb/ngFmiwjkSNz/dJwdxBYW sJWYdqyDBSJuJ7Hq3E9WCNtKYs35F2A1LAKqEi+/TQWr4RVwk1h3qRkszikQIfFoy2M2EJtR QFZi99nrTCA2s4C4xK0n85kgThWQWLLnPNTZohIvH/9jhbAVJZ40bmaBqNeTuDF1ChuErS2x bOFrZohdghInZz4BqxESkJbYcXIN4wRGsVlIVsxC0j4LSfssJO0LGFlWMQrmZhQbmBkm5yXr FWXm6uWllmxiBKcKDYMdjBP2ah1iFOBgVOLh/XbUyE+INbGsuDL3EKMEB7OSCG/KYkM/Id6U xMqq1KL8+KLSnNTiQ4wWwFCZyCzFnZwPTGN5JfHGBgYoHCVx3jBpAz8hgXRgUspOTS1ILYJp ZeLglGpgPHEj8vzHkOAp8uwzQvjDVhz3PLXRmuPihMLDq3tCQxMtHX+L+niyhZtPzGlun9o/ XWSthfVr5oISH5t7mxZXPrsnsev5HM4j7baLptye9ve4pNuKeQ5leXyrpn3SPH7++5zj4ZIf ku3NzMVer2M9tfDX/5vBAYIVohe4Jk5bEhI7YRVjVr75HyWW4oxEQy3mouJEAHzhybIuAwAA Subject: Re: [Simple] Comment on draft-ietf-msrp-sessmatch-13 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: Fri, 29 Jul 2011 15:45:38 -0000 I don't think I said that the middlebox initiates the new offer. Its clear t= he UA does that. ----- Original Message ----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, July 29, 2011 10:35 AM=0A= To: Andrew Allen; simple@ietf.org Subject: Re: [Simple] Comment on draft-ietf-msrp-sessmatch-13 Hi Andrew, The middlebox does not send a new offer - it is the task of the CEMA UA. The= middlebox simply decides to either enable MSRP B2BUA. We did not want to st= art specifying procedures abuot middleboxes sending offers etc. Having said that, one comment that you (and some others) have given is that= the middlebox needed to determine whether to enable MSRP B2BUA when it rece= ives the SDP offer, and I will address that. Thanks! Regards, Christer ________________________________________ From: simple-bounces@ietf.org [simple-bounces@ietf.org] On Behalf Of Andrew= Allen [aallen@rim.com] Sent: Friday, July 29, 2011 6:07 PM To: simple@ietf.org Subject: [Simple] Comment on draft-ietf-msrp-sessmatch-13 Christer I have reviewed this draft and I am basically supportive of it. One comment I have is that in 4.2 there is discussion of fallback behavior w= here the middlebox decides to act as B2BUA after it receives the first respo= nse based on a new offer within the same dialog. To act as a B2BUA the middl= ebox needs to determine to be a B2BUA when handling the dialog creating requ= est so the fallback scenario requires the MSRP endpoint to cancel the existi= ng dialog and send the revised offer in a new dialog creating request (not i= n a request on an existing dialog). Andrew --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. _______________________________________________ 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 --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful.