From Even.roni@huawei.com Tue Jul 7 12:41:58 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED81E28C2FF; Tue, 7 Jul 2009 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlm+lyPnAvA1; Tue, 7 Jul 2009 12:41:49 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 5737E28C540; Tue, 7 Jul 2009 12:41:49 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF009XMG07HT@szxga03-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF004LPG07XI@szxga03-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Received: from windows8d787f9 (bzq-82-81-156-32.red.bezeqint.net [82.81.156.32]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMF001JOFZNP9@szxml01-in.huawei.com>; Wed, 08 Jul 2009 03:40:55 +0800 (CST) Date: Tue, 07 Jul 2009 22:40:17 +0300 From: Roni Even To: sarvi@cisco.com, dburnett@voxeo.com Message-id: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw)" Content-language: en-us Thread-index: Acn/OlCXdRdlr834SLWofXw8dvS9rQ== X-Mailman-Approved-At: Wed, 08 Jul 2009 09:26:14 -0700 Cc: speechsc@ietf.org, oran@cisco.com, rai@ietf.org Subject: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 19:41:58 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I was assigned to do a RAI review of the draft. The draft looks ready for publication to me. I have some comments mostly editorial. The only issue I see that is not pure editorial is the issue of the different parameters like confidence threshold, sensitivity level (see comments 11, 13, 15, 16 and 17). I think that some clarification on the semantics and the scale (for example are the values linearly spaced) as well as when they are useful will be helpful to implementers. 1. In figure 1 Expand the abbreviations TTS, ASR, SV , SI and how they are related to the media resource types in 3.1 2. In figure 1 there is a SIP dialog between the MRCPv2 client and the media source/sink, what is this dialog, I only saw in section 4 a dialog between the client and server. 3. In section 3.2 you have "For example: sip:mrcpv2@example.net" twice one after the other. 4. In the example in section 4.2 you "a=cmid:1", cmid is specified later in the document so maybe you can add some reference to where it is specified 5. In the example is section 4.2 and in following examples you have "m=audio 49170 RTP/AVP 0 96" but do not have an rtpmap parameter for mapping 96 (dynamic payload type number) to a media encoding name. 6. In section 4.3 "Also note that more that one media session can be associated with a single resource if need be, but this scenario is not useful for the current set of resources". There is a typo the second "that" should be "than". I am also not sure if the current syntax in this document can support the mode. 7. In section 4.3 "The formatting of the"cmid" attribute in SDP RFC3388 [RFC4566]". I think you meant SDP grouping and need the reference to RFC 3388. 8. In section 5.1 "The message-length field specifies the length of the message, including the start-line" is the length in Bytes, there is no unit specified. 9. In section 6.3.1, typo you have "Verfication " instead of verification. It appears twice in the section. 10. In the example in section 7 you have "m=audio 0 RTP/AVP 0 1 3" payload type 1 was deleted from the IANA registry, maybe have another payload type number. 11. In section 9.4.1, 9.4.2 and 9.4.3 you specify confidence threshold, sensitivity level and speed vs accuracy. What is the scale here; is it linear between 0 and 1. What is the absolute value of the number, if you receive the same confidence level from two recognizers are they the same (e.g. when using context block to switch servers). For the speed vs accuracy, how does the client know what is the relation between the value and the number of available sessions, since this seems to be the reason for using this parameter. 12. In 9.4.9 and in 10.4.8, 11.4.11 what are the values for media-type-value, you also mention audio and video but it looks to me that this document only discusses voice. 13. In 9.4.35 and 9.4.36 what is the scale for the consistency here. How does one know what close means. What is the consistency between different recognizers. 14. In section 9.6.3.3 in the example (figure 2) confidence should be 0.75 and not 75 15. In section 10.4.1 it is not clear how you measure the sensitivity in order to specify, is it based on some SNR translated to 0 to 1 scale? 16. In 11.4.6 the same issue with the scale, how does the client know how to set a value when working with different speaker verification servers. 17. In 11.5.2.9 you state that the verification-score is not a probability, so what is it. How can the client decide if, for example, 0 is a good score for specifying the threshold. I also noticed that the values in the example in section 11.5.2.10 are very precise like 0.98514 is this the expected precision. The examples here and in section 11.11 do not show the threshold, if the threshold is required for this flow why not show it in the example? 18. In section 12.3 the suggestion is to use SRTP as the mandatory interoperability mode. If the reason for mandating SRTP is for a common mode you should also decide on a key exchange mechanism. I suggest you look at http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for discussion on media security. 19. In section13.7.2 you specify the attribute resource as session level yet in the example in section 4.2 it is a media level attribute. The same goes for the channel attribute Thanks Roni Even --Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi,

I was assigned to do a RAI review of the draft.  The draft looks ready = for publication to me. I have some comments mostly editorial. =

The only issue I see that is not pure editorial is the issue of the = different parameters like confidence threshold, sensitivity level (see comments = 11, 13, 15, 16 and 17). I think that some clarification on the semantics and the = scale (for example are the values linearly spaced) as well as when they are = useful will be helpful to implementers.

1.       In figure 1 Expand the abbreviations TTS, ASR, = SV , SI and how they are related to the media resource types in = 3.1

2.       In figure 1 there is a SIP dialog between the = MRCPv2 client and the media source/sink, what is this dialog, I only saw in = section 4 a dialog between the client and server.

3.       In section 3.2 you have = “For example: sip:mrcpv2@example.net” twice one = after the other.

 =

4.       In the example in section 4.2 = you “a=3Dcmid:1”, cmid is specified later in the document so = maybe you can add some reference to where it is specified

 =

5.       In the example is section 4.2 = and in following examples you have “m=3Daudio 49170 RTP/AVP 0 96” = but do not have an rtpmap parameter for mapping 96 (dynamic payload type number) to = a media encoding name.

 =

6.       In section 4.3 “Also = note that more that one media session can be associated with a single resource if = need be, but this scenario is not useful for the current set of = resources”. There is a typo the second “that” should be = “than”. I am also not sure if the current syntax in this document can support the = mode.

 =

 =

7.       In section 4.3 “The = formatting of the"cmid" attribute in SDP RFC3388 [RFC4566]”. I = think you meant SDP grouping and need the reference to RFC = 3388.

 =

 =

8.       In section 5.1 = “The = message-length field specifies the length of the message, including the = start-line” is the length in Bytes, there is no unit specified.

 =

9.       In section 6.3.1, typo you = have “Verfication “ instead of verification. It appears twice in = the section.

 =

10.   In the example in section 7 = you have “m=3Daudio 0 RTP/AVP 0 1 3” payload type 1 was deleted from = the IANA registry, maybe have another payload type number.

 =

11.   In section 9.4.1, 9.4.2 and = 9.4.3 you specify confidence threshold, sensitivity level and speed vs = accuracy. What is the scale here; is it linear between 0 and 1. What is the absolute = value of the number, if you receive the same confidence level from two = recognizers are they the same (e.g. when using context block to switch servers).  = For the speed vs accuracy, how does the client know what is the relation between = the value and the number of available sessions, since this seems to be the = reason for using this parameter.

 =

12.   In 9.4.9 and in 10.4.8, = 11.4.11 what are the values for media-type-value, you also mention audio and video = but it looks to me that this document only discusses = voice.

 =

13.   In 9.4.35 and 9.4.36 what is = the scale for the consistency here. How does one know what close means. What = is the consistency between different recognizers.

 =

14.   In section 9.6.3.3 in the = example (figure 2) confidence should be 0.75 and not 75

 =

15.   In section 10.4.1 it is not = clear how you measure the sensitivity in order to specify, is it based on some = SNR translated to 0 to 1 scale?

 =

16.   In 11.4.6 the same issue with = the scale, how does the client know how to set a value when working with = different speaker verification servers.

 =

17.   In 11.5.2.9 you state that = the verification-score is not a probability, so what is it. How can the = client decide if, for example, 0 is a good score for specifying the threshold.  I = also noticed that the values in the example in section 11.5.2.10 are very = precise like 0.98514 is this the expected precision. The examples here and in = section 11.11 do not show the threshold, if the threshold is required for this = flow why not show it in the example?

 =

18.   In section 12.3 the = suggestion is to use SRTP as the mandatory interoperability mode. If the reason for = mandating SRTP is for a common mode you should also decide on a key exchange = mechanism. I suggest you look at = http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for discussion on media security.

 =

19.   In section13.7.2 you specify = the attribute resource as session level yet in the example in section 4.2 it is a = media level attribute. The same goes for the channel attribute

 

Thanks=

 =

Roni Even

 =

 

--Boundary_(ID_tDM6/tBc+CJPdmIwZyVDuw)-- From Christian.Groves@nteczone.com Wed Jul 8 17:37:28 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E96A3A6879 for ; Wed, 8 Jul 2009 17:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0v04okBksUd for ; Wed, 8 Jul 2009 17:37:26 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by core3.amsl.com (Postfix) with ESMTP id 19E0F3A69B8 for ; Wed, 8 Jul 2009 17:37:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4BAIvYVEp20Oe3/2dsb2JhbAAI0SeECAWBOg X-IronPort-AV: E=Sophos;i="4.42,371,1243780200"; d="scan'208";a="390647708" Received: from ppp118-208-231-183.lns10.mel6.internode.on.net (HELO [127.0.0.1]) ([118.208.231.183]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2009 10:07:50 +0930 Message-ID: <4A553BD5.80106@nteczone.com> Date: Thu, 09 Jul 2009 10:37:41 +1000 From: Christian Groves User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: speechsc@ietf.org References: <4A2F20D4.3000409@nteczone.com> In-Reply-To: <4A2F20D4.3000409@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Even.roni@huawei.com Subject: Re: [Speechsc] Question about Verification X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 00:37:28 -0000 Hello, Can anyone explain the apparent contradiction between the text and the syntax below? Regards, Christian Christian Groves wrote: > Hello, > > I've been reviewing the verification section of > draft-ietf-speechsc-mrcpv2-19 there appears to be some contradiction > between the text and the syntax. i.e. > > Section 11.5.2.3. "Incremental" states: > > The first "" element MAY contain an "" > element with the incremental scores of how well the last utterance > matched the voiceprint. > > However section 16.3. "Verification Results Schema Definition" states: > * */* * > > > > > > * <------- ???* > > > > .../ > > I don't know if I'm reading this correctly but to me section 11.5.2.3 > doesn't say anything about incremental being used in subsequent > voices. So I would assume that it would not be part of the > restVoicePrintContent schema? > > Another example: > > Section 11.5.2.5. "Utterance-Length" > > This element MAY occur within either the "" or > "" elements within the first "" element. > However section 16.3 states: > / * <----------------- ???* > > > > > > > > * <-----------???* > > > / > > Again I don't know if I'm reading this correctly but the text for > utterance says its applicable for the first voiceprint but the schema > shows it only relevant for subsequent voiceprints??? > > Another example is: > Section 11.5.2.8. "Adapted" which states: > > This element is found within the "" element within the > verification results. > > However 16.3 states: > /** > > > > > > * * > > / > Again I'm confused as previous text says that certain elements are > applicable to the first voiceprint but the text does not state this > for the adapted element yet the schema shows it only belongs to the > first Voiceprint. > > Can anyone shed some slight on this? > > Regards, Christian > _______________________________________________ > Speechsc mailing list > Speechsc@ietf.org > https://www.ietf.org/mailman/listinfo/speechsc > Supplemental web site: > <http://www.standardstrack.com/ietf/speechsc> > From eburger@standardstrack.com Thu Jul 9 13:27:42 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B99EA28C274; Thu, 9 Jul 2009 13:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs+bFDJ7LUBa; Thu, 9 Jul 2009 13:27:41 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id A06E828C14F; Thu, 9 Jul 2009 13:27:41 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.174]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MP0Dm-0007xt-V2; Thu, 09 Jul 2009 13:27:59 -0700 Message-Id: From: Eric Burger To: Roni Even In-Reply-To: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> Content-Type: multipart/signed; boundary=Apple-Mail-7-428628199; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 9 Jul 2009 16:28:04 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.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: speechsc@ietf.org, Saravanan Shanmugham , rai@ietf.org Subject: Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:27:42 -0000 --Apple-Mail-7-428628199 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The reality is that NO ONE has implemented any security to date. The GENART reviewer raised the same issue, and so far the work group has the same response: MRCPv2 (the speechsc work group) is not planning on figuring out which of the seven key exchange mechanisms to use in SIP. We are counting on the community publishing something, and people using it. After all, we are the "using SIP for media resource control" work group, not the "media resource control work group using something like SIP for control." Does this work for you? On Jul 7, 2009, at 3:40 PM, Roni Even wrote: > [snip] > > > 18. In section 12.3 the suggestion is to use SRTP as the mandatory > interoperability mode. If the reason for mandating SRTP is for a > common mode you should also decide on a key exchange mechanism. I > suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 > for discussion on media security. --Apple-Mail-7-428628199 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MDkyMDI4MDRaMCMGCSqGSIb3 DQEJBDEWBBRC7T8KXqvYCOzBeU2QSO2QRvUbMjCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBjSveKBHQsG/3jap4YZvyqosUcvPoVNfz5u+9tQnE4RDIA uYj/srk5EUfJC5npCa7f2KvBDUL+qF68TIyIp2pnUi9vedSyAZH/94AwNI0rwCStuy7SCYMet9xA JEHzJQWxDRmaGG1wt4VtIldp2f7PF0Rgn4egOMsPelMEg/hsKXVOiLvqMlqVDcaP+7jg8JvyYq9R VImcVrmp+2OvAoDQPT1VRFHW31+fdlvPNcrDfYYPzMUY0Y1yhoV/W2gYAaZEJDt4S2D+BqgWpBDA FGfMlIihdyEATamhQRoiCHeY57bOBErJTeQF2Hq6lhPi0b/CtgBukp2lQfD0TJm1UtHdAAAAAAAA --Apple-Mail-7-428628199-- From AUDET@nortel.com Thu Jul 9 13:49:16 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09093A6D37; Thu, 9 Jul 2009 13:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.305 X-Spam-Level: X-Spam-Status: No, score=-6.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlYnKsp5xCbN; Thu, 9 Jul 2009 13:49:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1CDFB3A6D55; Thu, 9 Jul 2009 13:48:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n69KnDi06199; Thu, 9 Jul 2009 20:49:13 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 15:48:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8AAC1@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 thread-index: AcoA08qFd1S0dvASReCM8f8AHQdPFgAAoe5A References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> From: "Francois Audet" To: "Eric Burger" , "Roni Even" X-Mailman-Approved-At: Fri, 10 Jul 2009 08:28:56 -0700 Cc: speechsc@ietf.org, Saravanan Shanmugham , rai@ietf.org Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:49:17 -0000 Eric, I think you need to clarify the context of the following statement you=20 made: "The reality is that NO ONE has implemented any security to=20 date." Certainly, SRTP is widely implemented and deployed in many environements (e.g., Enteprise telephony for example). I am assuming that your comment was specific to MRCPv2? > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On=20 > Behalf Of Eric Burger > Sent: Thursday, July 09, 2009 13:28 > To: Roni Even > Cc: Daniel Burnett; speechsc@ietf.org; Saravanan Shanmugham;=20 > rai@ietf.org > Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 >=20 > The reality is that NO ONE has implemented any security to=20 > date. The GENART reviewer raised the same issue, and so far=20 > the work group has the same response: MRCPv2 (the speechsc=20 > work group) is not planning on figuring out which of the=20 > seven key exchange mechanisms to use in SIP. We are counting=20 > on the community publishing something, and people using it. =20 > After all, we are the "using SIP for media resource control"=20 > work group, not the "media resource control work group using=20 > something like SIP for control." >=20 > Does this work for you? >=20 > On Jul 7, 2009, at 3:40 PM, Roni Even wrote: >=20 > > [snip] > > > > > > 18. In section 12.3 the suggestion is to use SRTP as the=20 > mandatory =20 > > interoperability mode. If the reason for mandating SRTP is for a=20 > > common mode you should also decide on a key exchange mechanism. I=20 > > suggest you look=20 > > athttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 > > for discussion on media security. >=20 >=20 From Even.roni@huawei.com Thu Jul 9 13:57:07 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE6813A6866; Thu, 9 Jul 2009 13:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.556 X-Spam-Level: X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_SORBS_WEB=0.619, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC+1ttcJCOVH; Thu, 9 Jul 2009 13:57:07 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CF8D23A6405; Thu, 9 Jul 2009 13:57:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMJ0030C8VMF2@szxga03-in.huawei.com>; Fri, 10 Jul 2009 04:57:22 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMJ006CY8VMSR@szxga03-in.huawei.com>; Fri, 10 Jul 2009 04:57:22 +0800 (CST) Received: from windows8d787f9 (bzq-79-179-66-111.red.bezeqint.net [79.179.66.111]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMJ001HU8VGOC@szxml01-in.huawei.com>; Fri, 10 Jul 2009 04:57:22 +0800 (CST) Date: Thu, 09 Jul 2009 23:56:21 +0300 From: Roni Even In-reply-to: To: 'Eric Burger' Message-id: <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcoA08zySVmonQexS/CVwQ8mR6VuCgAAoPQg References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> X-Mailman-Approved-At: Fri, 10 Jul 2009 08:28:56 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org Subject: Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 20:57:07 -0000 Eric, My comment is that in this case in AVT we say that you do not need to mandate SRTP but mandate a security mechanism that can be not only SRTP but in a different layer like ipsec. This is why I gave a reference to the srtp-not-mandatory draft Roni > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Thursday, July 09, 2009 11:28 PM > To: Roni Even > Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; > rai@ietf.org > Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 > > The reality is that NO ONE has implemented any security to date. The > GENART reviewer raised the same issue, and so far the work group has > the same response: MRCPv2 (the speechsc work group) is not planning on > figuring out which of the seven key exchange mechanisms to use in > SIP. We are counting on the community publishing something, and > people using it. After all, we are the "using SIP for media resource > control" work group, not the "media resource control work group using > something like SIP for control." > > Does this work for you? > > On Jul 7, 2009, at 3:40 PM, Roni Even wrote: > > > [snip] > > > > > > 18. In section 12.3 the suggestion is to use SRTP as the mandatory > > interoperability mode. If the reason for mandating SRTP is for a > > common mode you should also decide on a key exchange mechanism. I > > suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- > not-mandatory-02 > > for discussion on media security. From eburger@standardstrack.com Sat Jul 11 18:09:26 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C79023A6812; Sat, 11 Jul 2009 18:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jHl+FvyKw-Qa; Sat, 11 Jul 2009 18:09:26 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 0B1D93A6811; Sat, 11 Jul 2009 18:09:26 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.100]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MPnZ4-0004Ve-3X; Sat, 11 Jul 2009 18:09:14 -0700 Message-Id: <1C686439-B153-4C31-86CC-1F9D9FD1914E@standardstrack.com> From: Eric Burger To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EE8AAC1@zrc2hxm0.corp.nortel.com> Content-Type: multipart/signed; boundary=Apple-Mail-25-618329138; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 11 Jul 2009 21:09:44 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1EE8AAC1@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.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: speechsc@ietf.org, rai@ietf.org Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 01:09:26 -0000 --Apple-Mail-25-618329138 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Correct: no one doing MRCPv2, not no one at all. On Jul 9, 2009, at 4:48 PM, Francois Audet wrote: > Eric, > > I think you need to clarify the context of the following statement you > made: "The reality is that NO ONE has implemented any security to > date." > > Certainly, SRTP is widely implemented and deployed in many > environements > (e.g., Enteprise telephony for example). > > I am assuming that your comment was specific to MRCPv2? > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >> Behalf Of Eric Burger >> Sent: Thursday, July 09, 2009 13:28 >> To: Roni Even >> Cc: Daniel Burnett; speechsc@ietf.org; Saravanan Shanmugham; >> rai@ietf.org >> Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 >> >> The reality is that NO ONE has implemented any security to >> date. The GENART reviewer raised the same issue, and so far >> the work group has the same response: MRCPv2 (the speechsc >> work group) is not planning on figuring out which of the >> seven key exchange mechanisms to use in SIP. We are counting >> on the community publishing something, and people using it. >> After all, we are the "using SIP for media resource control" >> work group, not the "media resource control work group using >> something like SIP for control." >> >> Does this work for you? >> >> On Jul 7, 2009, at 3:40 PM, Roni Even wrote: >> >>> [snip] >>> >>> >>> 18. In section 12.3 the suggestion is to use SRTP as the >> mandatory >>> interoperability mode. If the reason for mandating SRTP is for a >>> common mode you should also decide on a key exchange mechanism. I >>> suggest you look >>> athttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 >>> for discussion on media security. >> >> --Apple-Mail-25-618329138 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MTIwMTA5NDVaMCMGCSqGSIb3 DQEJBDEWBBSLjF/ijRHXRNN/J6TkgKZvLnoLLzCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBgAuiWVgljWGdb5ygWOntWgaSh9u8A4VAYaAjmK3Dy6nOa f8Vcz5P5e5zxOfz8JbTQftb+MzXNFBx0WhZI3iEiEjObMu39vOADHIDPugxrmBqHTCWrmOggGHxu NUsuzSgbRsqvxe46zPdXowxApucbWhzQ0rmrOS/2L7B589MRzVKCiGJK4iLjejGKZCBr7wLbBqAJ BJe9LKV6QY3CdwV0xYemQtFEe7BY4CtMzkB5HOTKB4kuGrRq3udQNqAdTe1Uw3mOXpwtcvqBzf0j SsgaeIkjG1qXNgBzYpPgz7fs05Nl69Hdf5LoyuXcJs0XDR6RoceufSsLdOlDbAta7yLQAAAAAAAA --Apple-Mail-25-618329138-- From AUDET@nortel.com Sat Jul 11 19:09:16 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 060DC3A6A77; Sat, 11 Jul 2009 19:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.057 X-Spam-Level: X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.125, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ul1bIq0lOMRI; Sat, 11 Jul 2009 19:09:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 539CC3A68D8; Sat, 11 Jul 2009 19:08:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6C27VE27018; Sun, 12 Jul 2009 02:07:31 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Sun, 12 Jul 2009 02:04:08 +0000 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <1ECE0EB50388174790F9694F77522CCF1EE8AAC1@zrc2hxm0.corp.nortel.com> <1C686439-B153-4C31-86CC-1F9D9FD1914E@standardstrack.com> Message-ID: From: "Francois Audet" To: "Eric Burger" In-Reply-To: <1C686439-B153-4C31-86CC-1F9D9FD1914E@standardstrack.com> Thread-Topic: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 thread-index: AcoClQqiv0Up8hA4Tb+dIp7jSFOHrQ== Content-Type: text/plain; format=flowed; delsp=yes; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPod Mail 7A341) Date: Sat, 11 Jul 2009 19:03:54 -0700 X-Mailman-Approved-At: Sun, 12 Jul 2009 08:45:37 -0700 Cc: speechsc@ietf.org, rai@ietf.org Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jul 2009 02:09:16 -0000 Danke On Jul 11, 2009, at 18:09, "Eric Burger" wrote: > > --Apple-Mail-25-618329138 > Content-Type: text/plain; > charset=US-ASCII; > format=flowed; > delsp=yes > Content-Transfer-Encoding: 7bit > > Correct: no one doing MRCPv2, not no one at all. > > On Jul 9, 2009, at 4:48 PM, Francois Audet wrote: > >> Eric, >> >> I think you need to clarify the context of the following statement >> you >> made: "The reality is that NO ONE has implemented any security to >> date." >> >> Certainly, SRTP is widely implemented and deployed in many >> environements >> (e.g., Enteprise telephony for example). >> >> I am assuming that your comment was specific to MRCPv2? >> >>> -----Original Message----- >>> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >>> Behalf Of Eric Burger >>> Sent: Thursday, July 09, 2009 13:28 >>> To: Roni Even >>> Cc: Daniel Burnett; speechsc@ietf.org; Sar From achaloyan@yahoo.com Tue Jul 14 02:44:24 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43C943A67E4 for ; Tue, 14 Jul 2009 02:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bF13SQUTaD9K for ; Tue, 14 Jul 2009 02:44:22 -0700 (PDT) Received: from n76.bullet.mail.sp1.yahoo.com (n76.bullet.mail.sp1.yahoo.com [98.136.44.48]) by core3.amsl.com (Postfix) with SMTP id DF6E53A68F0 for ; Tue, 14 Jul 2009 02:44:22 -0700 (PDT) Received: from [216.252.122.219] by n76.bullet.mail.sp1.yahoo.com with NNFMP; 14 Jul 2009 09:44:25 -0000 Received: from [67.195.9.82] by t4.bullet.sp1.yahoo.com with NNFMP; 14 Jul 2009 09:44:24 -0000 Received: from [67.195.9.98] by t2.bullet.mail.gq1.yahoo.com with NNFMP; 14 Jul 2009 09:44:24 -0000 Received: from [127.0.0.1] by omp102.mail.gq1.yahoo.com with NNFMP; 14 Jul 2009 09:44:24 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 704360.22074.bm@omp102.mail.gq1.yahoo.com Received: (qmail 7838 invoked by uid 60001); 14 Jul 2009 09:44:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1247564664; bh=6PGtjmTXhy7iihojsv08oW5n0ww+/Jh8Xuq5Hpgw1Ds=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kjrP4kcJsGw02o2JbkYiJ0TtUHFGQsEkPiRM2ExIzl2kbXMnYm3fUSk1htmyHWoLHFi7VamT8nOD8VNYb2n0tRo97cBIo0JLdpNZoJqlYFOr1dXXoFYkGAUqkX+0GZ0GkJBUiYhcUFsvTIwKVFwHOfSxFRo8EdGw3ZJ8slaWRt4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SSqhwA+BmdddtSmqOh9YtgAPoNjq/QKounPRHLADvW3Bwi9q6o/8BJ9HmJEwLXA5DW+ZaSZAIWTyWwTcKG6BcUac/qXvuXw6jVmlDKJsNjFtijFcqbxP79d91GYhvvP6PrIetpmpIa59C3+ikzcfjJHuI+nFJP77ZAMGdcFo160=; Message-ID: <441543.7572.qm@web111316.mail.gq1.yahoo.com> X-YMail-OSG: eM1wf8kVM1kaMWG0pcbN15Qa8D7mOp9TThBq1rX7mzGowibXVY.wTuOv7tmqRATaOj4f.KoL2stoj0fcg6tWPerSYc2an0xbuj0LzHrcjfF7x7zYrLXwMWRfRjoJECXT7qpPgvBp3L.zCFCIsbmFAS_AcTcz.72DSori4qT1XXjmw6rbjzPOMCzlUd1IRLroY3YRP285MXlrSKmpq2vMSR8.I2BRCboRDjdsJYyGtVOBWyo9ziJ.3CpBrhl3sI6fgE80khvFKg9fLaByPaT7sohMiHdWWFZXnLkQMn.4B_MBnfEnxggFD3QlypCj1uR6wALZ0N9tWAyt08TwsTFO7nheLMrRGv5AywZjg_gwYZh7y9_VQa68sg-- Received: from [91.198.247.201] by web111316.mail.gq1.yahoo.com via HTTP; Tue, 14 Jul 2009 02:44:23 PDT X-Mailer: YahooMailRC/1358.21 YahooMailWebService/0.7.289.15 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> Date: Tue, 14 Jul 2009 02:44:23 -0700 (PDT) From: Arsen Chaloyan To: Roni Even , sarvi@cisco.com, dburnett@voxeo.com In-Reply-To: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1520693546-1247564663=:7572" Cc: speechsc@ietf.org, oran@cisco.com, rai@ietf.org Subject: Re: [Speechsc] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 09:44:24 -0000 --0-1520693546-1247564663=:7572 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,=0ATwo small issues left you may want to fix.=0A=0A- Section 9.4.30=0AMe= dia type should be "text/plain" instead of "plain/text"=0Ahttp://www.w3.org= /TR/2004/REC-speech-synthesis-20040907/=0A=0A- Find BARGE-IN-OCCURED replac= e with BARGE-IN-OCCURRED=0AThere are 3 such occurrences in the text.=0A=0AT= hanks,=0AArsen.=0A=0A=0A=0A=0A________________________________=0AFrom: Roni= Even =0ATo: sarvi@cisco.com; dburnett@voxeo.com=0ACc= : speechsc@ietf.org; oran@cisco.com; rai@ietf.org=0ASent: Wednesday, July 8= , 2009 12:40:17 AM=0ASubject: [Speechsc] RAI review of draft-ietf-speechsc-= mrcpv2-19=0A=0A =0AHi,=0AI was=0Aassigned to do a RAI review of the draft. = The draft looks ready for=0Apublication to me. I have some comments mostly= editorial. =0AThe=0Aonly issue I see that is not pure editorial is the iss= ue of the different=0Aparameters like confidence threshold, sensitivity lev= el (see comments 11, 13,=0A15, 16 and 17). I think that some clarification = on the semantics and the scale=0A(for example are the values linearly space= d) as well as when they are useful=0Awill be helpful to implementers.=0A1. = In figure 1 Expand the abbreviations TTS, ASR, SV , SI=0Aand how they= are related to the media resource types in 3.1=0A2. In figure 1 ther= e is a SIP dialog between the MRCPv2=0Aclient and the media source/sink, wh= at is this dialog, I only saw in section 4=0Aa dialog between the client an= d server.=0A3. In section 3.2 you have =E2=80=9CFor=0Aexample: sip:mr= cpv2@example.net=E2=80=9D twice one after=0Athe other.=0A =0A4. In th= e example in section 4.2 you=0A=E2=80=9Ca=3Dcmid:1=E2=80=9D, cmid is specif= ied later in the document so maybe you=0Acan add some reference to where it= is specified=0A =0A5. In the example is section 4.2 and in=0Afollowi= ng examples you have =E2=80=9Cm=3Daudio 49170 RTP/AVP 0 96=E2=80=9D but do = not=0Ahave an rtpmap parameter for mapping 96 (dynamic payload type number)= to a=0Amedia encoding name.=0A =0A6. In section 4.3 =E2=80=9CAlso no= te that=0Amore that one media session can be associated with a single resou= rce if need=0Abe, but this scenario is not useful for the current set of re= sources=E2=80=9D.=0AThere is a typo the second =E2=80=9Cthat=E2=80=9D shoul= d be =E2=80=9Cthan=E2=80=9D. I=0Aam also not sure if the current syntax in = this document can support the mode.=0A =0A =0A7. In section 4.3 =E2= =80=9CThe formatting=0Aof the"cmid" attribute in SDP RFC3388 [RFC4566]=E2= =80=9D. I think you=0Ameant SDP grouping and need the reference to RFC 3388= ..=0A =0A =0A8. In section 5.1 =E2=80=9CThe message-length=0Afield spe= cifies the length of the message, including the start-line=E2=80=9D is=0Ath= e length in Bytes, there is no unit specified.=0A =0A9. In section 6.= 3.1, typo you have=0A=E2=80=9CVerfication =E2=80=9C instead of verification= .. It appears twice in the=0Asection.=0A =0A10. In the example in section = 7 you have=0A=E2=80=9Cm=3Daudio 0 RTP/AVP 0 1 3=E2=80=9D payload type 1 was= deleted from the IANA=0Aregistry, maybe have another payload type number.= =0A =0A11. In section 9.4.1, 9.4.2 and 9.4.3=0Ayou specify confidence thr= eshold, sensitivity level and speed vs accuracy. What=0Ais the scale here; = is it linear between 0 and 1. What is the absolute value of=0Athe number, i= f you receive the same confidence level from two recognizers are=0Athey the= same (e.g. when using context block to switch servers). For the=0Aspeed v= s accuracy, how does the client know what is the relation between the=0Aval= ue and the number of available sessions, since this seems to be the reason= =0Afor using this parameter.=0A =0A12. In 9.4.9 and in 10.4.8, 11.4.11 wh= at=0Aare the values for media-type-value, you also mention audio and video = but it=0Alooks to me that this document only discusses voice.=0A =0A13. I= n 9.4.35 and 9.4.36 what is the=0Ascale for the consistency here. How does = one know what close means. What is the=0Aconsistency between different reco= gnizers.=0A =0A14. In section 9.6.3.3 in the example=0A(figure 2) confide= nce should be 0.75 and not 75=0A =0A15. In section 10.4.1 it is not clear= =0Ahow you measure the sensitivity in order to specify, is it based on some= SNR=0Atranslated to 0 to 1 scale?=0A =0A16. In 11.4.6 the same issue wit= h the=0Ascale, how does the client know how to set a value when working wit= h different=0Aspeaker verification servers.=0A =0A17. In 11.5.2.9 you sta= te that the=0Averification-score is not a probability, so what is it. How c= an the client decide=0Aif, for example, 0 is a good score for specifying th= e threshold. I also=0Anoticed that the values in the example in section 11= ..5.2.10 are very precise=0Alike 0.98514 is this the expected precision. The= examples here and in section=0A11.11 do not show the threshold, if the thr= eshold is required for this flow why=0Anot show it in the example?=0A =0A18= .. In section 12.3 the suggestion is to=0Ause SRTP as the mandatory intero= perability mode. If the reason for mandating=0ASRTP is for a common mode yo= u should also decide on a key exchange mechanism. I=0Asuggest you look at h= ttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-02 for discussi= on on media security.=0A =0A19. In section13.7.2 you specify the attribut= e=0Aresource as session level yet in the example in section 4.2 it is a med= ia level=0Aattribute. The same goes for the channel attribute=0A =0AThanks= =0A =0ARoni=0AEven --0-1520693546-1247564663=:7572 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,
Two small issues left you may want to fix.

- Section = 9.4.30
Media type should be "text/plain" instead of "plain/text"
http://www.w3.org/TR/2004/REC-speech-synthesis-20040907/<= /span>

- Find BARGE-IN-OCCURED replace with BARGE-IN-OCCURRED
The= re are 3 such occurrences in the text.

Thanks,
Arsen.

=
From: Roni Even <Even.roni@huawei.com><= br>To: sarvi@cisco.com; dburnett@voxeo.com
Cc:= speechsc@ietf.org; oran@cisco.com; rai@ietf.org
Sent: Wednesday, July 8, 2009 12:40:17 AM
<= span style=3D"font-weight: bold;">Subject: [Speechsc] RAI review= of draft-ietf-speechsc-mrcpv2-19

=0A=0A=0A=0A =0A =0A=0A=0A=0A=0A
=0A=0A

I was=0Aassigned to do a RAI review of the draf= t.  The draft looks ready for=0Apublication to me. I have some comment= s mostly editorial.

=0A=0A

The=0Aonly issue I see that is n= ot pure editorial is the issue of the different=0Aparameters like confidenc= e threshold, sensitivity level (see comments 11, 13,=0A15, 16 and 17). I th= ink that some clarification on the semantics and the scale=0A(for example a= re the values linearly spaced) as well as when they are useful=0Awill be he= lpful to implementers.

=0A=0A

1.      =0A= In figure 1 Expand the abbreviations TTS, ASR, SV , SI=0Aand how t= hey are related to the media resource types in 3.1

=0A=0A

2.    &nb= sp; =0AIn figure 1 there is a SIP dialog betwee= n the MRCPv2=0Aclient and the media source/sink, what is this dialog, I onl= y saw in section 4=0Aa dialog between the client and server.

=0A= =0A

<= span style=3D"">3.      =0AIn section 3.2 you have =E2=80= =9CFor=0Aexample: sip:mrcpv2@example.net=E2=80=9D twice one a= fter=0Athe other.

=0A=0A

 

=0A=0A

4.     &nb= sp;=0AIn the e= xample in section 4.2 you=0A=E2=80=9Ca=3Dcmid:1=E2=80=9D, cmid is specified= later in the document so maybe you=0Acan add some reference to where it is= specified

=0A=0A

 = ;

=0A=0A

= 5.      =0A<= /span>In the example = is section 4.2 and in=0Afollowing examples you have =E2=80=9Cm=3Daudio 4917= 0 RTP/AVP 0 96=E2=80=9D but do not=0Ahave an rtpmap parameter for mapping 9= 6 (dynamic payload type number) to a=0Amedia encoding name.

=0A= =0A

 

=0A=0A

6.      =0AIn section 4.3 =E2=80=9CAlso note that= =0Amore that one media session can be associated with a single resource if = need=0Abe, but this scenario is not useful for the current set of resources= =E2=80=9D.=0AThere is a typo the second =E2=80=9Cthat=E2=80=9D should be = =E2=80=9Cthan=E2=80=9D. I=0Aam also not sure if the current syntax in this = document can support the mode.

=0A=0A

<= span style=3D"font-size: 11pt; font-family: "Calibri","sans-= serif";">  

=0A=0A

 

=0A=0A

7.     = ; =0AIn s= ection 4.3 =E2=80=9CThe formatting=0Aof the"cmid" attribute in SDP RFC3388 = [RFC4566]=E2=80=9D. I think you=0Ameant SDP grouping and need the reference= to RFC 3388.

=0A=0A

&n= bsp;

=0A=0A

 

=0A=0A

8.      =0A= In section 5.1 =E2=80= =9CThe message-length=0Afield specifies the length of= the message, including the start-line=E2=80=9D is=0Athe length in Bytes, t= here is no unit specified.

=0A=0A

 

=0A=0A

9.    =   =0AIn section 6.3.1, typo you have=0A=E2=80=9CVerfication =E2=80=9C instead o= f verification. It appears twice in the=0Asection.

=0A=0A

 

=0A=0A

10.=   =0AIn the example in section 7 you have=0A=E2=80=9Cm=3Daudio 0 RTP/AVP 0 1= 3=E2=80=9D payload type 1 was deleted from the IANA=0Aregistry, maybe have= another payload type number.

=0A=0A

 

=0A=0A

11.  =0AIn section 9.4.1, 9= ..4.2 and 9.4.3=0Ayou specify confidence threshold, sensitivity level and sp= eed vs accuracy. What=0Ais the scale here; is it linear between 0 and 1. Wh= at is the absolute value of=0Athe number, if you receive the same confidenc= e level from two recognizers are=0Athey the same (e.g. when using context b= lock to switch servers).  For the=0Aspeed vs accuracy, how does the cl= ient know what is the relation between the=0Avalue and the number of availa= ble sessions, since this seems to be the reason=0Afor using this parameter.=

=0A=0A

  =0A=0A

12.  =0AIn 9.4.9 and in 10.4.8, 11.4.11 what=0Aare the v= alues for media-type-value, you also mention audio and video but it=0Alooks= to me that this document only discusses voice.

=0A=0A

 

=0A=0A

13.<= span style=3D"font-family: "Times New Roman"; font-style: normal;= font-variant: normal; font-weight: normal; font-size: 7pt; line-height: no= rmal; font-size-adjust: none; font-stretch: normal; -x-system-font: none;">=   =0AIn 9.4.35 and 9.4.36 what is the=0Ascale for the consistency here. How doe= s one know what close means. What is the=0Aconsistency between different re= cognizers.

=0A=0A

 = ;

=0A=0A

= 14.  =0AIn section 9.6.3.3 in the example=0A(f= igure 2) confidence should be 0.75 and not 75

=0A=0A

 

=0A=0A

15.&nbs= p; =0AIn = section 10.4.1 it is not clear=0Ahow you measure the sensitivity in order t= o specify, is it based on some SNR=0Atranslated to 0 to 1 scale?

= =0A=0A

 

=0A=0A16.  =0AIn 11.4.6 the same issue with the=0Ascale, how does the cli= ent know how to set a value when working with different=0Aspeaker verificat= ion servers.

=0A=0A

&nb= sp;

=0A=0A

17.  =0A<= span dir=3D"ltr">In 11.5.2.9 you state that the=0Aver= ification-score is not a probability, so what is it. How can the client dec= ide=0Aif, for example, 0 is a good score for specifying the threshold. = ; I also=0Anoticed that the values in the example in section 11.5.2.10 are = very precise=0Alike 0.98514 is this the expected precision. The examples he= re and in section=0A11.11 do not show the threshold, if the threshold is re= quired for this flow why=0Anot show it in the example?

=0A=0A

 

=0A=0A

18.  =0AIn section 12.3 the suggestion is to=0Ause SRTP as the mandator= y interoperability mode. If the reason for mandating=0ASRTP is for a common= mode you should also decide on a key exchange mechanism. I=0Asuggest you l= ook at http://tools.ietf.org/html/draft-ietf-avt-srtp-no= t-mandatory-02=0Afor discussion on media security.

= =0A=0A

 

=0A=0A

19.  =0A= In section13.7.2 you specify the attribute=0Aresource as ses= sion level yet in the example in section 4.2 it is a media level=0Aattribut= e. The same goes for the channel attribute

=0A=0A

 

=0A=0A

T= hanks

=0A=0A

 

=0A=0A

Roni=0AEven =0A=0A

 

=0A=0A=

 

=0A=0A
=0A=0A
--0-1520693546-1247564663=:7572-- From dyork@voxeo.com Tue Jul 14 13:27:14 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F0E3A67E2; Tue, 14 Jul 2009 13:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id db3gDZjUuEQ9; Tue, 14 Jul 2009 13:27:13 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id 6A7BF3A67D3; Tue, 14 Jul 2009 13:27:12 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 49415385; Tue, 14 Jul 2009 20:16:18 +0000 Message-Id: <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> From: Dan York To: Roni Even In-Reply-To: <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-146-859920856 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Jul 2009 16:16:16 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 15 Jul 2009 08:14:53 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 20:27:14 -0000 --Apple-Mail-146-859920856 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Roni, The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC). ------ Based on your comments and the srtp-not-mandatory draft (which was just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be that you are advocating something more like this: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Is that an accurate summary of your feedback? Would that text be acceptable? Regards, Dan On Jul 9, 2009, at 4:56 PM, Roni Even wrote: > Eric, > My comment is that in this case in AVT we say that you do not need to > mandate SRTP but mandate a security mechanism that can be not only > SRTP but > in a different layer like ipsec. This is why I gave a reference to the > srtp-not-mandatory draft > > Roni > >> -----Original Message----- >> From: Eric Burger [mailto:eburger@standardstrack.com] >> Sent: Thursday, July 09, 2009 11:28 PM >> To: Roni Even >> Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; >> rai@ietf.org >> Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 >> >> The reality is that NO ONE has implemented any security to date. The >> GENART reviewer raised the same issue, and so far the work group has >> the same response: MRCPv2 (the speechsc work group) is not planning >> on >> figuring out which of the seven key exchange mechanisms to use in >> SIP. We are counting on the community publishing something, and >> people using it. After all, we are the "using SIP for media resource >> control" work group, not the "media resource control work group using >> something like SIP for control." >> >> Does this work for you? >> >> On Jul 7, 2009, at 3:40 PM, Roni Even wrote: >> >>> [snip] >>> >>> >>> 18. In section 12.3 the suggestion is to use SRTP as the mandatory >>> interoperability mode. If the reason for mandating SRTP is for a >>> common mode you should also decide on a key exchange mechanism. I >>> suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- >> not-mandatory-02 >>> for discussion on media security. > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo --Apple-Mail-146-859920856 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3= is:
------
12.3.  Media session =
protection 
   
Sensitive data is also =
carried on media sessions terminating on
   MRCPv2 servers (the other end of a media channel may or may not be on
   the MRCPv2 client).  This data includes the user's spoken utterances
   and the output of text-to-speech operations.  MRCPv2 servers MUST
   support SRTP for protection of audio media sessions.  MRCPv2 clients
   that originate or consume audio similarly MUST support SRTP.
   Alternative media channel protection MAY be used if desired (e.g.
   IPSEC).
------

Based on your comments = and the srtp-not-mandatory draft (which was just revised to h= ttp://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my = understanding would be that you are advocating something more like = this:

------
12.3. Media =
session protection 
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances   =
 and the output of text-to-speech operations. MRCPv2 servers MUST =
support a security mechanism for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support a =
security mechanism for protection of the =
audio. 
------

Is that an accurate summary of your feedback?  Would that text be = acceptable?

Regards,
Dan

=
On Jul 9, 2009, at 4:56 PM, Roni Even wrote:

Eric,
My comment is that in this case in AVT we = say that you do not need to
mandate SRTP but mandate a security = mechanism that can be  not only SRTP but
in a different layer = like ipsec. This is why I gave a reference to the
srtp-not-mandatory = draft

Roni

-----Original = Message-----
From: Eric Burger = [mailto:eburger@standardstrack.c= om]
Sent: Thursday, July = 09, 2009 11:28 PM
To: Roni = Even
Cc: Saravanan Shanmugham; = Daniel Burnett; speechsc@ietf.org;
<= blockquote type=3D"cite">rai@ietf.org
Subject: Re: RAI review of = draft-ietf-speechsc-mrcpv2-19

The reality is = that NO ONE has implemented any security to date. = The
GENART reviewer raised the = same issue, and so far the work group has
the same response: MRCPv2 (the speechsc work group) is not = planning on
figuring out which = of the seven key exchange mechanisms to use = in
SIP.  We are counting = on the community publishing something, and
people using it.  After all, we are the "using SIP = for media resource
control" = work group, not the "media resource control work group = using
something like SIP for = control."

Does this work = for you?

On Jul 7, 2009, = at 3:40 PM, Roni Even wrote:

[snip]


18.   In section 12.3 = the suggestion is to use SRTP as the = mandatory
interoperability mode. If the = reason for mandating SRTP is for = a
common mode you should also decide on a key exchange = mechanism. I
suggest you look athttp://tools.ietf= .org/html/draft-ietf-avt-srtp-
not-mandatory-02
for discussion on media = security.


___________________________= ____________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mail= man/listinfo/rai

-- 
Dan York, = Director of Conversations
Voxeo = Corporation   http://www.voxeo.com  dyork@voxeo.com
Phone: +1-407-455-5859    Skype: = danyork  









= --Apple-Mail-146-859920856-- From ron.even.tlv@gmail.com Tue Jul 14 13:56:56 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFA6C3A68F3; Tue, 14 Jul 2009 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H75WHTzQNi6; Tue, 14 Jul 2009 13:56:55 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 541A73A6851; Tue, 14 Jul 2009 13:56:53 -0700 (PDT) Received: by bwz28 with SMTP id 28so1034595bwz.37 for ; Tue, 14 Jul 2009 13:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=JXBuGNY13Nyu1sy0p+Wp+49jE5Gkdyp/do+/prc/r2A=; b=hiYsj2q4nLgbmfLoJBdnn/N+QPbZA8W4H3ECq5yEpo0wEHMizUgCUikGUODvtODG2Z G+lp04JAPEl4+2xaQNlnJa2EAcdBNZGiYAaGg/FbDpUQOvYzGErRwfI3EFM2QEIrpGM5 0PSsVWsdRu1W9f8EIcgYceM+lWdolRA5XpCdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=w19DpgoWUL7PFQEVQvVlHyJ2VdCvI7hQSBkrc6/jkm7gLdRqDp8/KRhBazipYD3j+q 9THXVKs4koAwBxOdeyMaN+l/zhRsgrV9/fzDAHG8oyuMw3EieLhTuyHA3GUA0ZSX2wbj kBMW406u7SLdbjMvU9bRh2aRQ0NDy2jKR+Wqs= Received: by 10.103.233.11 with SMTP id k11mr3670845mur.42.1247604955582; Tue, 14 Jul 2009 13:55:55 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id 25sm23845825mul.20.2009.07.14.13.55.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 13:55:54 -0700 (PDT) From: "Roni Even" To: "'Dan York'" , "'Roni Even'" References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> In-Reply-To: <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> Date: Tue, 14 Jul 2009 23:55:27 +0300 Message-ID: <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A5D_01CA04DE.90AD2E80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoEwZDrIBeDdtFURVOXNaXHDHQ5wQAA1HiA Content-Language: en-us X-Mailman-Approved-At: Wed, 15 Jul 2009 08:14:53 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 20:56:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0A5D_01CA04DE.90AD2E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan, This is the general idea. The major reason is that there are various ways to protect the data and if you are not mandating one for interoperability then it can be more general For example we have the following text when discussing security in the RTP payloads specifications. RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] recommended. Other mechanisms that may be used are IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist. Roni Even From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan York Sent: Tuesday, July 14, 2009 11:16 PM To: Roni Even Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Roni, The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC). ------ Based on your comments and the srtp-not-mandatory draft (which was just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be that you are advocating something more like this: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Is that an accurate summary of your feedback? Would that text be acceptable? Regards, Dan On Jul 9, 2009, at 4:56 PM, Roni Even wrote: Eric, My comment is that in this case in AVT we say that you do not need to mandate SRTP but mandate a security mechanism that can be not only SRTP but in a different layer like ipsec. This is why I gave a reference to the srtp-not-mandatory draft Roni -----Original Message----- From: Eric Burger [mailto:eburger@standardstrack.com] Sent: Thursday, July 09, 2009 11:28 PM To: Roni Even Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; rai@ietf.org Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 The reality is that NO ONE has implemented any security to date. The GENART reviewer raised the same issue, and so far the work group has the same response: MRCPv2 (the speechsc work group) is not planning on figuring out which of the seven key exchange mechanisms to use in SIP. We are counting on the community publishing something, and people using it. After all, we are the "using SIP for media resource control" work group, not the "media resource control work group using something like SIP for control." Does this work for you? On Jul 7, 2009, at 3:40 PM, Roni Even wrote: [snip] 18. In section 12.3 the suggestion is to use SRTP as the mandatory interoperability mode. If the reason for mandating SRTP is for a common mode you should also decide on a key exchange mechanism. I suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- not-mandatory-02 for discussion on media security. _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo ------=_NextPart_000_0A5D_01CA04DE.90AD2E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

This is the general idea. The major reason is that there = are various ways to protect the data and if you are not mandating one for interoperability then it can be more general

 

For example we have the following text when discussing = security in the RTP payloads specifications.

 

RTP packets using the payload format defined in this specification

   are subject to the security considerations = discussed in the RTP

   specification [RFC3550] and any appropriate = RTP profile.  The main

   security considerations for the RTP packet = carrying the RTP payload

   format defined within this memo are = confidentiality, integrity, and

   source authenticity.  Confidentiality = is achieved by encryption of

   the RTP payload.  Integrity of the RTP = packets is achieved through a

   suitable cryptographic integrity protection = mechanism.  Such a

   cryptographic system may also allow the = authentication of the source

   of the payload.  A suitable security = mechanism for this RTP payload

   format should provide confidentiality, = integrity protection, and at

   least source authentication capable of = determining if an RTP packet

   is from a member of the RTP = session.

 

   Note that the appropriate mechanism to = provide security to RTP and

   payloads following this memo may vary.  = It is dependent on the

   application, the transport, and the = signaling protocol employed.

   Therefore, a single mechanism is not = sufficient, although if

   suitable, usage of the Secure Real-time = Transport Protocol (SRTP)

   [RFC3711] recommended.  Other = mechanisms that may be used are IPsec

   [RFC4301] Transport Layer Security (TLS) = [RFC5246] (RTP over TCP);

   other alternatives may = exist.

 

Roni Even

 

From:= rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of = Dan York
Sent: Tuesday, July 14, 2009 11:16 PM
To: Roni Even
Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI review of = draft-ietf-speechsc-mrcpv2-19

 

Roni,

 

------
12.3. =
Media session protection  
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances and the output =
of text-to-speech operations. MRCPv2 servers MUST support SRTP for =
protection of audio media sessions. MRCPv2 clients that originate or =
consume audio similarly MUST support SRTP. Alternative media channel =
protection MAY be used if desired (e.g. =
IPSEC).

------

 

Based on your comments and the srtp-not-mandatory = draft (which was just revised to = http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be that you are advocating something more like = this:

 

------

12.3. Media session =
protection 
Sensitive=
 data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances   =
 and the output of text-to-speech operations. MRCPv2 servers MUST =
support a security mechanism for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support a =
security mechanism for protection of the =
audio. 

------

 

Is that an accurate summary of your feedback? =  Would that text be acceptable?

 

Regards,

Dan

 

On Jul 9, 2009, at 4:56 PM, Roni Even = wrote:



Eric,
My comment is that in this case in AVT we say that you do not need = to
mandate SRTP but mandate a security mechanism that can be  not only = SRTP but
in a different layer like ipsec. This is why I gave a reference to = the
srtp-not-mandatory draft

Roni


-----Original Message-----

From: Eric Burger [mailto:eburger@standardstrack.= com]

Sent: Thursday, July 09, 2009 11:28 = PM

To: Roni Even

Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org;

rai@ietf.org

Subject: Re: RAI review of = draft-ietf-speechsc-mrcpv2-19

 

The reality is that NO ONE has implemented any = security to date. The

GENART reviewer raised the same issue, and so far = the work group has

the same response: MRCPv2 (the speechsc work group) = is not planning on

figuring out which of the seven key exchange = mechanisms to use in

SIP.  We are counting on the community = publishing something, and

people using it.  After all, we are the = "using SIP for media resource

control" work group, not the "media = resource control work group using

something like SIP for = control."

 

Does this work for you?

 

On Jul 7, 2009, at 3:40 PM, Roni Even = wrote:

 

[snip]

 

 

18.   In section 12.3 the suggestion is = to use SRTP as the mandatory

interoperability mode. If the reason for mandating = SRTP is for a

common mode you should also decide on a key = exchange mechanism. I

suggest you look athttp://tools.iet= f.org/html/draft-ietf-avt-srtp-

not-mandatory-02

for discussion on media security.



_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

 

-- 

Dan York, Director of Conversations

Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com

=

Phone: +1-407-455-5859    Skype: danyork  

 

Join the Voxeo conversation:

 



 

 

 

 

 

 

------=_NextPart_000_0A5D_01CA04DE.90AD2E80-- From dyork@voxeo.com Tue Jul 14 14:13:02 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D34293A6A3F; Tue, 14 Jul 2009 14:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkrYvp774Kpa; Tue, 14 Jul 2009 14:13:00 -0700 (PDT) Received: from voxeo.com (mmail.voxeo.com [66.193.54.208]) by core3.amsl.com (Postfix) with SMTP id BE93A3A6B50; Tue, 14 Jul 2009 14:11:06 -0700 (PDT) Received: from [66.65.229.48] (account dyork HELO pc-00148.lodestar2.local) by voxeo.com (CommuniGate Pro SMTP 5.2.3) with ESMTPSA id 49416723; Tue, 14 Jul 2009 21:10:40 +0000 Message-Id: From: Dan York To: "Roni Even" In-Reply-To: <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> Content-Type: multipart/alternative; boundary=Apple-Mail-147-863182515 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Jul 2009 17:10:38 -0400 References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> X-Mailer: Apple Mail (2.930.3) X-Mailman-Approved-At: Wed, 15 Jul 2009 08:14:53 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org, 'Roni Even' Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 21:13:02 -0000 --Apple-Mail-147-863182515 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Roni, So as the RAI reviewer, are you okay with the text I suggested: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Or would you prefer this text that includes the recommendation of SRTP? (Which I noticed you did in the RTP payloads spec - and it makes sense to me to provide some basic guidance.): ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. If appropriate, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. ------ Regards, Dan Regards, Dan On Jul 14, 2009, at 4:55 PM, Roni Even wrote: > Dan, > This is the general idea. The major reason is that there are various > ways to protect the data and if you are not mandating one for > interoperability then it can be more general > > For example we have the following text when discussing security in > the RTP payloads specifications. > > RTP packets using the payload format defined in this specification > are subject to the security considerations discussed in the RTP > specification [RFC3550] and any appropriate RTP profile. The main > security considerations for the RTP packet carrying the RTP payload > format defined within this memo are confidentiality, integrity, and > source authenticity. Confidentiality is achieved by encryption of > the RTP payload. Integrity of the RTP packets is achieved > through a > suitable cryptographic integrity protection mechanism. Such a > cryptographic system may also allow the authentication of the > source > of the payload. A suitable security mechanism for this RTP payload > format should provide confidentiality, integrity protection, and at > least source authentication capable of determining if an RTP packet > is from a member of the RTP session. > > Note that the appropriate mechanism to provide security to RTP and > payloads following this memo may vary. It is dependent on the > application, the transport, and the signaling protocol employed. > Therefore, a single mechanism is not sufficient, although if > suitable, usage of the Secure Real-time Transport Protocol (SRTP) > [RFC3711] recommended. Other mechanisms that may be used are IPsec > [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); > other alternatives may exist. > > Roni Even > > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf > Of Dan York > Sent: Tuesday, July 14, 2009 11:16 PM > To: Roni Even > Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org > Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 > > Roni, > > The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 > is: > ------ > 12.3. Media session protection > Sensitive data is also carried on media sessions terminating on > MRCPv2 servers (the other end of a media channel may or may not be > on the MRCPv2 client). This data includes the user's spoken > utterances and the output of text-to-speech operations. MRCPv2 > servers MUST support SRTP for protection of audio media sessions. > MRCPv2 clients that originate or consume audio similarly MUST > support SRTP. Alternative media channel protection MAY be used if > desired (e.g. IPSEC). > ------ > > Based on your comments and the srtp-not-mandatory draft (which was > just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 > ), my understanding would be that you are advocating something more > like this: > > ------ > 12.3. Media session protection > Sensitive data is also carried on media sessions terminating on > MRCPv2 servers (the other end of a media channel may or may not be > on the MRCPv2 client). This data includes the user's spoken > utterances and the output of text-to-speech operations. MRCPv2 > servers MUST support a security mechanism for protection of audio > media sessions. MRCPv2 clients that originate or consume audio > similarly MUST support a security mechanism for protection of the > audio. > ------ > > Is that an accurate summary of your feedback? Would that text be > acceptable? > > Regards, > Dan > > On Jul 9, 2009, at 4:56 PM, Roni Even wrote: > > > Eric, > My comment is that in this case in AVT we say that you do not need to > mandate SRTP but mandate a security mechanism that can be not only > SRTP but > in a different layer like ipsec. This is why I gave a reference to the > srtp-not-mandatory draft > > Roni > > > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com] > Sent: Thursday, July 09, 2009 11:28 PM > To: Roni Even > Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; > rai@ietf.org > Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 > > The reality is that NO ONE has implemented any security to date. The > GENART reviewer raised the same issue, and so far the work group has > the same response: MRCPv2 (the speechsc work group) is not planning on > figuring out which of the seven key exchange mechanisms to use in > SIP. We are counting on the community publishing something, and > people using it. After all, we are the "using SIP for media resource > control" work group, not the "media resource control work group using > something like SIP for control." > > Does this work for you? > > On Jul 7, 2009, at 3:40 PM, Roni Even wrote: > > [snip] > > > 18. In section 12.3 the suggestion is to use SRTP as the mandatory > interoperability mode. If the reason for mandating SRTP is for a > common mode you should also decide on a key exchange mechanism. I > suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- > not-mandatory-02 > for discussion on media security. > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > > -- > Dan York, Director of Conversations > Voxeo Corporation http://www.voxeo.com dyork@voxeo.com > Phone: +1-407-455-5859 Skype: danyork > > Join the Voxeo conversation: > Blogs: http://blogs.voxeo.com > Twitter: http://twitter.com/voxeo http://twitter.com/danyork > Facebook: http://www.facebook.com/voxeo > > > > > > > > > -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo --Apple-Mail-147-863182515 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Roni,

So as = the RAI reviewer, are you okay with the text I = suggested:
------
12.3. Media session =
protection 
Sensitive data is also =
carried on media sessions terminating on MRCPv2 servers (the other end =
of a media channel may or may not be on the MRCPv2 client). This data =
includes the user's spoken utterances    and the output of =
text-to-speech operations. MRCPv2 servers MUST support a security =
mechanism for protection of audio media sessions. MRCPv2 clients that =
originate or consume audio similarly MUST support a security mechanism =
for protection of the =
audio. 
------

Or would you prefer this text that includes the recommendation of = SRTP?  (Which I noticed you did in the RTP payloads spec - and it = makes sense to me to provide some basic = guidance.):
------
12.3. Media session =
protection 
Sensitive data is also =
carried on media sessions terminating on MRCPv2 servers (the other end =
of a media channel may or may not be on the MRCPv2 client). This data =
includes the user's spoken utterances    and the output of =
text-to-speech operations. MRCPv2 servers MUST support a security =
mechanism for protection of audio media sessions. MRCPv2 clients that =
originate or consume audio similarly MUST support a security mechanism =
for protection of the audio. If appropriate, usage of the Secure =
Real-time Transport Protocol (SRTP) [RFC3711] is =
recommended.
------

Regards,
Dan

Regards,
D= an

On Jul 14, 2009, at = 4:55 PM, Roni Even wrote:

This = is the general idea. The major reason is that there are various ways to = protect the data and if you are not mandating one for interoperability = then it can be more general
For = example we have the following text when discussing security in the RTP = payloads specifications.
 
RTP packets using the payload = format defined in this specification
   are subject to the = security considerations discussed in the RTP
   specification = [RFC3550] and any appropriate RTP profile.  The = main
   cryptographic system may also allow the = authentication of the source
   of the = payload.  A suitable security mechanism for this RTP = payload
Roni = Even
 rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan = York
Sent: Tuesday, July 14, 2009 = 11:16 PM
To: Roni = Even
Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI review of = draft-ietf-speechsc-mrcpv2-19
 
The current text = at  is:
12.3. =
Media session protection  
Sensitive data is also carried on =
media sessions terminating on MRCPv2 servers (the other end of a media =
channel may or may not be on the MRCPv2 client). This data includes the =
user's spoken utterances and the output of text-to-speech operations. =
MRCPv2 servers MUST support SRTP for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support =
SRTP. Alternative media channel protection MAY be used if desired (e.g. =
IPSEC).
Subject: Re: = RAI review of = draft-ietf-speechsc-mrcpv2-19
The reality is that NO ONE has = implemented any security to date. = The
GENART reviewer raised the same issue, and = so far the work group has
the same = response: MRCPv2 (the speechsc work group) is not planning = on
figuring out which of the seven key exchange = mechanisms to use in
SIP.  We = are counting on the community publishing something, = and
people using it.  After all, we are the = "using SIP for media resource
control" work = group, not the "media resource control work group = using
something like SIP for = control."
Does this work for = you?
On Jul 7, 2009, at 3:40 PM, = Roni Even wrote:
18. =   In section 12.3 the suggestion is to use SRTP as the = mandatory
common mode = you should also decide on a key exchange mechanism. = I
Phone: +1-407-455-5859    Skype: = danyork  
Join the Voxeo = conversation:




= --Apple-Mail-147-863182515-- From ron.even.tlv@gmail.com Tue Jul 14 15:01:43 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA2F3A635F; Tue, 14 Jul 2009 15:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdfQN+LUIwT3; Tue, 14 Jul 2009 15:01:41 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id A6F433A6E60; Tue, 14 Jul 2009 15:01:24 -0700 (PDT) Received: by fxm18 with SMTP id 18so3101102fxm.37 for ; Tue, 14 Jul 2009 15:00:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=jKIvUZ2UzofS+UNKUoF/lXaPGvA3D8jZA8LscnDzTUI=; b=a0hN5icK67E/9U7kdht3MmSc2ZNYXfMRUzg/4oXhib0JpwSio3gwQOPg70Kf/5s8H5 YhX9CvijbG7ZNGHMXvFbPX7OzOHplal2wgfudMGArU5oRorX6Az4m1wDXOioTt1s/ArA kS3UNvsSO6tj60ges99fhz2lBp4fKJDx1gnz8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; b=GVe0Eanxh9srxlnumxNB/mwvqUlNoZNK1pqnFPbhG2avak2ZqIc4ghzH8pFAQZG2ZI znEJ2Zw+WUVyI7uNeffnNAPFd4uDgEK2LMrzw0zGN/wa8YjDdTb1lKuDNsLWT1Tbr40g 2pyOOffHG2j7zXzLpRe09+rJ5FsPehXdp+JsU= Received: by 10.103.131.13 with SMTP id i13mr3715652mun.64.1247607397188; Tue, 14 Jul 2009 14:36:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-66-37.red.bezeqint.net [79.179.66.37]) by mx.google.com with ESMTPS id n10sm30032606mue.17.2009.07.14.14.36.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Jul 2009 14:36:36 -0700 (PDT) From: "Roni Even" To: "'Dan York'" References: <033101c9ff3a$cbe33160$63a99420$%roni@huawei.com> <05e101ca00d7$bc996aa0$35cc3fe0$%roni@huawei.com> <53ADC9B8-F9D2-4B27-A6D8-96B507911343@voxeo.com> <4a5cf0da.190c660a.3ec0.58fa@mx.google.com> In-Reply-To: Date: Wed, 15 Jul 2009 00:36:08 +0300 Message-ID: <4a5cfa64.0aa5660a.1918.ffff94d6@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A87_01CA04E4.4014F3D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoEx4wp7NhipJKURgG7lWCJ5mWaSgAAykQQ Content-Language: en-us X-Mailman-Approved-At: Wed, 15 Jul 2009 08:14:53 -0700 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org, 'Roni Even' Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 22:01:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0A87_01CA04E4.4014F3D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dan, I prefer the text that recommends SRTP (It is a SHOULD and not a MUST). The text we currently have is based on the security reviews we got for RTP payload specifications, and as you can see it addresses the issue of why not to mandate SRTP. Roni From: Dan York [mailto:dyork@voxeo.com] Sent: Wednesday, July 15, 2009 12:11 AM To: Roni Even Cc: 'Roni Even'; 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Roni, So as the RAI reviewer, are you okay with the text I suggested: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Or would you prefer this text that includes the recommendation of SRTP? (Which I noticed you did in the RTP payloads spec - and it makes sense to me to provide some basic guidance.): ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. If appropriate, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. ------ Regards, Dan Regards, Dan On Jul 14, 2009, at 4:55 PM, Roni Even wrote: Dan, This is the general idea. The major reason is that there are various ways to protect the data and if you are not mandating one for interoperability then it can be more general For example we have the following text when discussing security in the RTP payloads specifications. RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] recommended. Other mechanisms that may be used are IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist. Roni Even From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan York Sent: Tuesday, July 14, 2009 11:16 PM To: Roni Even Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Roni, The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC). ------ Based on your comments and the srtp-not-mandatory draft (which was just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be that you are advocating something more like this: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Is that an accurate summary of your feedback? Would that text be acceptable? Regards, Dan On Jul 9, 2009, at 4:56 PM, Roni Even wrote: Eric, My comment is that in this case in AVT we say that you do not need to mandate SRTP but mandate a security mechanism that can be not only SRTP but in a different layer like ipsec. This is why I gave a reference to the srtp-not-mandatory draft Roni -----Original Message----- From: Eric Burger [mailto:eburger@standardstrack.com] Sent: Thursday, July 09, 2009 11:28 PM To: Roni Even Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; rai@ietf.org Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 The reality is that NO ONE has implemented any security to date. The GENART reviewer raised the same issue, and so far the work group has the same response: MRCPv2 (the speechsc work group) is not planning on figuring out which of the seven key exchange mechanisms to use in SIP. We are counting on the community publishing something, and people using it. After all, we are the "using SIP for media resource control" work group, not the "media resource control work group using something like SIP for control." Does this work for you? On Jul 7, 2009, at 3:40 PM, Roni Even wrote: [snip] 18. In section 12.3 the suggestion is to use SRTP as the mandatory interoperability mode. If the reason for mandating SRTP is for a common mode you should also decide on a key exchange mechanism. I suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- not-mandatory-02 for discussion on media security. _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo ------=_NextPart_000_0A87_01CA04E4.4014F3D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan,

I prefer the text that recommends SRTP (It is a SHOULD = and not a MUST). The text we currently have is based on the security reviews we = got for RTP payload specifications, and as you can see it addresses the issue of = why not to mandate SRTP.

Roni

 

From:= Dan York [mailto:dyork@voxeo.com]
Sent: Wednesday, July 15, 2009 12:11 AM
To: Roni Even
Cc: 'Roni Even'; 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI review of = draft-ietf-speechsc-mrcpv2-19

 

Roni,

 

So as the RAI reviewer, are you okay with the text = I suggested:

------

12.3. Media session =
protection 
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances   =
 and the output of text-to-speech operations. MRCPv2 servers MUST =
support a security mechanism for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support a =
security mechanism for protection of the =
audio. 

------

 

Or would you prefer this text that includes the recommendation of SRTP?  (Which I noticed you did in the RTP = payloads spec - and it makes sense to me to provide some basic = guidance.):

------

12.3. Media session =
protection 
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances   =
 and the output of text-to-speech operations. MRCPv2 servers MUST =
support a security mechanism for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support a =
security mechanism for protection of the audio. If =
appropriate, usage of the Secure Real-time Transport Protocol =
(SRTP) [RFC3711] is =
recommended.

------

 

Regards,

Dan

 

Regards,

Dan

 

On Jul 14, 2009, at 4:55 PM, Roni Even = wrote:



Dan,

This is the general idea. The major reason is that there = are various ways to protect the data and if you are not mandating one for interoperability then it can be more general

 

For example we have the following text when discussing = security in the RTP payloads specifications.

 

RTP packets using the payload format defined in this specification

   are subject to the security considerations discussed in the RTP

   specification [RFC3550] and any appropriate = RTP profile.  The main

   security considerations for the RTP packet = carrying the RTP payload

   format defined within this memo are confidentiality, integrity, and

   source authenticity.  Confidentiality = is achieved by encryption of

   the RTP payload.  Integrity of the RTP = packets is achieved through a

   suitable cryptographic integrity protection mechanism.  Such a

   cryptographic system may also allow the authentication of the source

   of the payload.  A suitable security = mechanism for this RTP payload

   format should provide confidentiality, = integrity protection, and at

   least source authentication capable of = determining if an RTP packet

   is from a member of the RTP = session.

 

   Note that the appropriate mechanism to = provide security to RTP and

   payloads following this memo may vary.  = It is dependent on the

   application, the transport, and the = signaling protocol employed.

   Therefore, a single mechanism is not = sufficient, although if

   suitable, usage of the Secure Real-time = Transport Protocol (SRTP)

   [RFC3711] recommended.  Other = mechanisms that may be used are IPsec

   [RFC4301] Transport Layer Security (TLS) = [RFC5246] (RTP over TCP);

   other alternatives may exist.

 

Roni Even

 

From:=  = rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan York
Sent: Tuesday, = July 14, 2009 11:16 PM
To: Roni Even
Cc: 'Daniel = Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: = [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

 

Roni,

 

------
12.3. Media session protection  
Sensitive data is also carried on media sessions terminating on MRCPv2 =
servers (the other end of a media channel may or may not be on the =
MRCPv2 client). This data includes the user's spoken utterances and the =
output of text-to-speech operations. MRCPv2 servers MUST support SRTP =
for protection of audio media sessions. MRCPv2 clients that originate or =
consume audio similarly MUST support SRTP. Alternative media channel =
protection MAY be used if desired (e.g. IPSEC).

------

 

Based on your comments = and the srtp-not-mandatory draft (which was just revised to = http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be = that you are advocating something more like this:

 

------

12.3. Media session =
protection 
Sensitive data is also carried on media sessions terminating on =
MRCPv2 servers (the other end of a media channel may or may not be on =
the MRCPv2 client). This data includes the user's spoken utterances =
   and the output of text-to-speech operations. MRCPv2 servers =
MUST support a security mechanism for protection of audio media =
sessions. MRCPv2 clients that originate or consume audio similarly MUST =
support a security mechanism for protection of the =
audio. 

------

 

Is that an accurate = summary of your feedback?  Would that text be = acceptable?

 

Regards,

Dan

 

On Jul 9, 2009, at 4:56 = PM, Roni Even wrote:




Eric,
My comment is that in this case in AVT we say that you do not need = to
mandate SRTP but mandate a security mechanism that can be  not only = SRTP but
in a different layer like ipsec. This is why I gave a reference to = the
srtp-not-mandatory draft

Roni



-----Original = Message-----

Sent: Thursday, July = 09, 2009 11:28 PM

To: Roni = Even

Cc: Saravanan = Shanmugham; Daniel Burnett; speechsc@ietf.org;

Subject: Re: RAI review = of draft-ietf-speechsc-mrcpv2-19

 

The reality is that NO = ONE has implemented any security to date. The

GENART reviewer raised = the same issue, and so far the work group has

the same response: = MRCPv2 (the speechsc work group) is not planning on

figuring out which of = the seven key exchange mechanisms to use in

SIP.  We are = counting on the community publishing something, and

people using it. =  After all, we are the "using SIP for media resource

control" work = group, not the "media resource control work group using

something like SIP for = control."

 

Does this work for = you?

 

On Jul 7, 2009, at 3:40 = PM, Roni Even wrote:

 

[snip]

 

 

18.   In = section 12.3 the suggestion is to use SRTP as the mandatory

interoperability mode. = If the reason for mandating SRTP is for a

common mode you should = also decide on a key exchange mechanism. I

not-mandatory-02

for discussion on media = security.



_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/m= ailman/listinfo/rai

 

-- 

Dan York, Director of Conversations

Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com

Phone: +1-407-455-5859    Skype: danyork  

 

Join the Voxeo conversation:

Facebook: http://www.facebook.com/voxeo<= /span>

 




 

 

 

 

 

 

 

-- 

Dan York, Director of Conversations

Voxeo Corporation   http://www.voxeo.com  dyork@voxeo.com

=

Phone: +1-407-455-5859    Skype: danyork  

 

Join the Voxeo conversation:

 



 

 

 

 

 

 

------=_NextPart_000_0A87_01CA04E4.4014F3D0-- From judith@jmarkowitz.com Wed Jul 15 10:30:27 2009 Return-Path: X-Original-To: speechsc@core3.amsl.com Delivered-To: speechsc@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E063A683A for ; Wed, 15 Jul 2009 10:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-M8p5mgaD6e for ; Wed, 15 Jul 2009 10:30:27 -0700 (PDT) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by core3.amsl.com (Postfix) with ESMTP id DDD273A6BF8 for ; Wed, 15 Jul 2009 10:30:25 -0700 (PDT) Received: from mail.networksolutionsemail.com (ns-omr7.mgt.netsol.com [10.49.6.70]) by omr7.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id n6FHTMcE013222 for ; Wed, 15 Jul 2009 13:29:24 -0400 Message-Id: <200907151729.n6FHTMcE013222@omr7.networksolutionsemail.com> Received: (qmail 25960 invoked by uid 78); 15 Jul 2009 17:29:21 -0000 Received: from unknown (HELO JMarkowitz) (judith@jmarkowitz.com@24.148.52.60) by ns-omr7.lb.hosting.dc2.netsol.com with SMTP; 15 Jul 2009 17:29:21 -0000 From: "Judith Markowitz" To: "'Roni Even'" , "'Dan York'" Date: Wed, 15 Jul 2009 12:28:25 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CA0547.C0955730" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcoEx4wp7NhipJKURgG7lWCJ5mWaSgAAykQQACmXH9A= In-Reply-To: <4a5cfa64.0aa5660a.1918.ffff94d6@mx.google.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: speechsc@ietf.org, 'Saravanan Shanmugham' , rai@ietf.org, 'Roni Even' Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 X-BeenThere: speechsc@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Speech Services Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 17:30:27 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002C_01CA0547.C0955730 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I want to support the position of recommending but not mandating. The approach used needs to comply with the policies and procedures of an organization. It could very well be that those policies and procedures are far more stringent than anything that would be mandated by MRCP V2. So, if a particular approach or technology is mandated the use of MRCP may be rejected because the security is not adequate or proper. Judith Markowitz J. Markowitz, Consultants 5801 N. Sheridan Rd, #19A Chicago, IL 60660 773-769-9243 judith@jmarkowitz.com _____ From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, July 14, 2009 4:36 PM To: 'Dan York' Cc: speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org; 'Roni Even' Subject: Re: [Speechsc] [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Dan, I prefer the text that recommends SRTP (It is a SHOULD and not a MUST). The text we currently have is based on the security reviews we got for RTP payload specifications, and as you can see it addresses the issue of why not to mandate SRTP. Roni From: Dan York [mailto:dyork@voxeo.com] Sent: Wednesday, July 15, 2009 12:11 AM To: Roni Even Cc: 'Roni Even'; 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Roni, So as the RAI reviewer, are you okay with the text I suggested: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Or would you prefer this text that includes the recommendation of SRTP? (Which I noticed you did in the RTP payloads spec - and it makes sense to me to provide some basic guidance.): ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. If appropriate, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] is recommended. ------ Regards, Dan Regards, Dan On Jul 14, 2009, at 4:55 PM, Roni Even wrote: Dan, This is the general idea. The major reason is that there are various ways to protect the data and if you are not mandating one for interoperability then it can be more general For example we have the following text when discussing security in the RTP payloads specifications. RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification [RFC3550] and any appropriate RTP profile. The main security considerations for the RTP packet carrying the RTP payload format defined within this memo are confidentiality, integrity, and source authenticity. Confidentiality is achieved by encryption of the RTP payload. Integrity of the RTP packets is achieved through a suitable cryptographic integrity protection mechanism. Such a cryptographic system may also allow the authentication of the source of the payload. A suitable security mechanism for this RTP payload format should provide confidentiality, integrity protection, and at least source authentication capable of determining if an RTP packet is from a member of the RTP session. Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable, usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711] recommended. Other mechanisms that may be used are IPsec [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over TCP); other alternatives may exist. Roni Even From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan York Sent: Tuesday, July 14, 2009 11:16 PM To: Roni Even Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19 Roni, The current text at http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-19#section-12.3 is: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support SRTP for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support SRTP. Alternative media channel protection MAY be used if desired (e.g. IPSEC). ------ Based on your comments and the srtp-not-mandatory draft (which was just revised to http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be that you are advocating something more like this: ------ 12.3. Media session protection Sensitive data is also carried on media sessions terminating on MRCPv2 servers (the other end of a media channel may or may not be on the MRCPv2 client). This data includes the user's spoken utterances and the output of text-to-speech operations. MRCPv2 servers MUST support a security mechanism for protection of audio media sessions. MRCPv2 clients that originate or consume audio similarly MUST support a security mechanism for protection of the audio. ------ Is that an accurate summary of your feedback? Would that text be acceptable? Regards, Dan On Jul 9, 2009, at 4:56 PM, Roni Even wrote: Eric, My comment is that in this case in AVT we say that you do not need to mandate SRTP but mandate a security mechanism that can be not only SRTP but in a different layer like ipsec. This is why I gave a reference to the srtp-not-mandatory draft Roni -----Original Message----- From: Eric Burger [mailto:eburger@standardstrack.com] Sent: Thursday, July 09, 2009 11:28 PM To: Roni Even Cc: Saravanan Shanmugham; Daniel Burnett; speechsc@ietf.org; rai@ietf.org Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19 The reality is that NO ONE has implemented any security to date. The GENART reviewer raised the same issue, and so far the work group has the same response: MRCPv2 (the speechsc work group) is not planning on figuring out which of the seven key exchange mechanisms to use in SIP. We are counting on the community publishing something, and people using it. After all, we are the "using SIP for media resource control" work group, not the "media resource control work group using something like SIP for control." Does this work for you? On Jul 7, 2009, at 3:40 PM, Roni Even wrote: [snip] 18. In section 12.3 the suggestion is to use SRTP as the mandatory interoperability mode. If the reason for mandating SRTP is for a common mode you should also decide on a key exchange mechanism. I suggest you look athttp://tools.ietf.org/html/draft-ietf-avt-srtp- not-mandatory-02 for discussion on media security. _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo -- Dan York, Director of Conversations Voxeo Corporation http://www.voxeo.com dyork@voxeo.com Phone: +1-407-455-5859 Skype: danyork Join the Voxeo conversation: Blogs: http://blogs.voxeo.com Twitter: http://twitter.com/voxeo http://twitter.com/danyork Facebook: http://www.facebook.com/voxeo ------=_NextPart_000_002C_01CA0547.C0955730 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I want to support the position of recommending but not mandating. The approach used needs to comply with = the policies and procedures of an organization. =

It could very well be that those = policies and procedures are far more stringent than anything that would be = mandated by MRCP V2. So, if a particular approach

or  technology is mandated the = use of MRCP may be rejected because the security is not adequate or proper. =

 

Judith = Markowitz

 

J. Markowitz, = Consultants

5801 N. Sheridan Rd, = #19A

Chicago, IL 60660

773-769-9243

judith@jmarkowitz.com

 

 

From: speechsc-bounces@ietf.org [mailto:speechsc-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, July 14, = 2009 4:36 PM
To: 'Dan York'
Cc: speechsc@ietf.org; = 'Saravanan Shanmugham'; rai@ietf.org; 'Roni Even'
Subject: Re: [Speechsc] = [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

 

Dan,

I prefer = the text that recommends SRTP (It is a SHOULD and not a MUST). The text we = currently have is based on the security reviews we got for RTP payload specifications, = and as you can see it addresses the issue of why not to mandate = SRTP.

Roni

 <= /o:p>

From: Dan = York [mailto:dyork@voxeo.com]
Sent: Wednesday, July 15, = 2009 12:11 AM
To: Roni Even
Cc: 'Roni Even'; 'Daniel = Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI = review of draft-ietf-speechsc-mrcpv2-19

 

Roni,

 

So as the RAI reviewer, are you okay with the text I = suggested:

------

12.3. Media session =
protection 
Sensitive data is also carried on media sessions =
terminating on MRCPv2 servers (the other end of a media channel may or =
may not be on the MRCPv2 client). This data includes the user's spoken =
utterances    and the output of text-to-speech operations. =
MRCPv2 servers MUST support a security mechanism for protection of audio =
media sessions. MRCPv2 clients that originate or consume audio similarly =
MUST support a security mechanism for protection of the =
audio. 

------

 

Or would you prefer this text that includes the recommendation = of SRTP?  (Which I noticed you did in the RTP payloads spec - and it makes = sense to me to provide some basic guidance.):

------

12.3. Media session =
protection 
Sensitive data is also carried on media sessions =
terminating on MRCPv2 servers (the other end of a media channel may or =
may not be on the MRCPv2 client). This data includes the user's spoken =
utterances    and the output of text-to-speech operations. =
MRCPv2 servers MUST support a security mechanism for protection of audio =
media sessions. MRCPv2 clients that originate or consume audio similarly =
MUST support a security mechanism for protection of the audio. If =
appropriate, usage of the Secure Real-time Transport Protocol =
(SRTP) [RFC3711] is =
recommended.

------

 

Regards,

Dan

 

Regards,

Dan

 

On Jul 14, 2009, at 4:55 PM, Roni Even = wrote:

 

Dan,<= /font>

This is the = general idea. The major reason is that there are various ways to protect the = data and if you are not mandating one for interoperability then it can be more = general

 

For example = we have the following text when discussing security in the RTP payloads = specifications.

 

RTP packets = using the payload format defined in this specification

  = are subject to the security considerations discussed in the = RTP

  = specification [RFC3550] and any appropriate RTP profile.  The = main

  = security considerations for the RTP packet carrying the RTP = payload

  = format defined within this memo are confidentiality, integrity, = and

  = source authenticity.  Confidentiality is achieved by encryption = of

  = the RTP payload.  Integrity of the RTP packets is achieved through = a

  = suitable cryptographic integrity protection mechanism.  Such = a

  = cryptographic system may also allow the authentication of the = source

  = of the payload.  A suitable security mechanism for this RTP = payload

  = format should provide confidentiality, integrity protection, and = at

  = least source authentication capable of determining if an RTP = packet

  = is from a member of the RTP session.

 

  = Note that the appropriate mechanism to provide security to RTP = and

  = payloads following this memo may vary.  It is dependent on = the

  = application, the transport, and the signaling protocol = employed.

  = Therefore, a single mechanism is not sufficient, although = if

  = suitable, usage of the Secure Real-time Transport Protocol = (SRTP)

  = [RFC3711] recommended.  Other mechanisms that may be used are = IPsec

  = [RFC4301] Transport Layer Security (TLS) [RFC5246] (RTP over = TCP);

  = other alternatives may exist.

 

Roni = Even

 

From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of Dan = York
Sent: Tuesday, July 14, 2009 11:16 = PM
To: Roni Even
Cc: 'Daniel Burnett'; speechsc@ietf.org; 'Saravanan Shanmugham'; rai@ietf.org
Subject: Re: [RAI] RAI review of draft-ietf-speechsc-mrcpv2-19

 

Roni,

=

  

------=

12.3. Media =
session protection  
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances and the output =
of text-to-speech operations. MRCPv2 servers MUST support SRTP for =
protection of audio media sessions. MRCPv2 clients that originate or =
consume audio similarly MUST support SRTP. Alternative media channel =
protection MAY be used if desired (e.g. =
IPSEC).

------

 

Based on your comments and the = srtp-not-mandatory draft (which was just revised to = http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory-03 ), my understanding would be = that you are advocating something more like this:

 

------ 

12.3. Media =
session protection 
Sensitive =
data is also carried on media sessions terminating on MRCPv2 servers =
(the other end of a media channel may or may not be on the MRCPv2 =
client). This data includes the user's spoken utterances   =
 and the output of text-to-speech operations. MRCPv2 servers MUST =
support a security mechanism for protection of audio media sessions. =
MRCPv2 clients that originate or consume audio similarly MUST support a =
security mechanism for protection of the =
audio. 

------

 

Is that an accurate summary of = your feedback?  Would that text be = acceptable?

 

Regards,<= /p>

Dan

 

On Jul 9, 2009, at 4:56 PM, Roni = Even wrote:



Eric,
My comment is that in this case in AVT we say that you do not need = to
mandate SRTP but mandate a security mechanism that can be  not only = SRTP but
in a different layer like ipsec. This is why I gave a reference to = the
srtp-not-mandatory draft

Roni


-----Original = Message-----

Sent: Thursday, July 09, 2009 = 11:28 PM

To: Roni = Even

Cc: Saravanan Shanmugham; Daniel = Burnett; speechsc@ietf.org;

Subject: Re: RAI review of draft-ietf-speechsc-mrcpv2-19

 

The reality is that NO ONE has = implemented any security to date. The

GENART reviewer raised the same = issue, and so far the work group has

the same response: MRCPv2 (the = speechsc work group) is not planning on

figuring out which of the seven = key exchange mechanisms to use in

SIP.  We are counting on the community publishing something, and

people using it.  After all, = we are the "using SIP for media resource

control" work group, not the "media resource control work group = using

something like SIP for = control."

 

Does this work for = you?

 

On Jul 7, 2009, at 3:40 PM, Roni = Even wrote:

 

[snip]

 

 

18.   In section 12.3 = the suggestion is to use SRTP as the mandatory

interoperability mode. If the = reason for mandating SRTP is for a

common mode you should also = decide on a key exchange mechanism. I

not-mandatory-02=

for discussion on media = security.



_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/m= ailman/listinfo/rai

 

-- 

Dan York, = Director of Conversations

Voxeo = Corporation   http://www.voxeo.com  dyork@voxeo.com

Phone: +1-407-455-5859    Skype: danyork  

 =

Join the = Voxeo conversation:

Blogs: http://blogs.voxeo.com<= font color=3Dblack>

Facebook: http://www.facebook.com/voxeo<= /span>

 =



 =

 =

 =

 =

 

 

 

-- =

Dan York, = Director of Conversations

Voxeo = Corporation   http://www.voxeo.com  dyork@voxeo.com

Phone: +1-407-455-5859    Skype: danyork  

 

Join the = Voxeo conversation:

 

 

 

 

 

 

 

 

------=_NextPart_000_002C_01CA0547.C0955730--